Towards the beginning of what is popularly known as the World Wide Web, there was JavaScript. JavaScript has been around since 1995 when Brendan Eich created the language to support Netscape, the now sadly defunct yet aesthetically pleasing web browser that was revolutionary for its time. Since then, the ECMAScript standard has served to underpin web development, representing the vast majority of applications that run in the web browser.

More recently, WebAssembly (Wasm) — which actually has been around for a while — has emerged. After the World Wide Web Consortium (W3C) named it as a web standard in 2019, it has thus become the fourth web standard with HTML, CSS and JavaScript. But while web browser applications have represented Wasm’s central and historical use case, again, the point is that it is designed to run anywhere on a properly configured CPU — this is where Wasm and JavaScript both bifurcate and become more integrated for some use cases.

Wasm and JavaScript remain closely linked, yet Wasm is very much about other things in addition to JavaScript. In a nutshell, Wasm’s original purpose to help JavaScript run more efficiently in the web browser remains a key component of their integration. That integration now extends beyond the web browser, and into edge and server applications for which JavaScript alone has not been the best fit.

This is due to how Wasm runs in a binary format on a CPU level. And lest we forget, unlike JavaScript, Wasm is not a programming language. One of the main beauties of Wasm is that its functionality enables it to accommodate a number of different languages in addition to JavaScript, including Python, Rust, of course, as well as Go, .NET, C++, Java and PHP.

So, WebAssembly can both integrate JavaScript when needed, but it is not limited to integrating JavaScript, of course. This integration and use with JavaScript has been a cornerstone of the symbiosis between WebAssembly and JavaScript, especially in the sphere of web applications.

This is because Wasm can give JavaScript a performance boost by compiling the otherwise interpreted language, and its runtime, into Wasm modules, Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack. code that is already compiled will generally run faster than code that still needs to be interpreted at runtime, such as JavaScript, he said.

Wasm and JavaScript integration works well for a wide range of applications. They include browser-based machine learning at edge locations, performance-hungry browser games, augmented and virtual reality apps that require low-latency execution, and generally, applications that need to be able to start up in a rapid manner, Volk said.

Further, while JavaScript is a great general-purpose language, sometimes it makes sense “to be able to play to the strengths of another language,” Fermyon Technologies CEO and co-founder Matt Butcher told The New Stack. “Heavy-duty number crunching might be more efficiently implemented in C++ or Rust. A package in Python might already do exactly what you need,” Butcher said. “Or you may be saddled with a complex piece of legacy code that you really need to run in the browser. WebAssembly unlocks these use cases.”

A Shared History

Indeed, JavaScript and WebAssembly’s historical co-evolution are complementary since Wasm was made about 20 years after JavaScript — aiming to expand JavaScript use cases to more performance-hungry application workloads, Volk said.

“For pure compute performance, as well as for such tasks as image processing, WebAssembly has certainly shown its merit as being much faster than JavaScript. But arguably the context is much more complex than that,” Volk said. “It is not really a question all of the time as to whether faster compute times matter as much, such as the need for JavaScript code for lighter coding tasks for mobile and Web applications.”

While the historical importance of WebAssembly’s interaction model may have been to create a way for browser-based JavaScript code to interact with libraries written in other languages, it is WebAssembly’s resulting design that is proving to be most important, Butcher said. “WebAssembly makes few assumptions about the external environment. Importantly, it does not assume JavaScript,” he said. “That has made it easy for Wasm to evolve beyond the browser context.”

The new component model specification is a case in point. This is because it describes how any WebAssembly binary can import and export functions to be consumed by any other WebAssembly binary, Butcher said. “No JavaScript necessary — that is well beyond the original scope of WebAssembly, and yet can be achieved because of the way the original specification was written,” Butcher said.

Can We Say WASM Is Better?

For pure compute performance, as well as for such tasks as image processing, WebAssembly has certainly shown its merit as being much faster than JavaScript. But arguably the context is much more complex than that. It is not really a question all of the time as to whether faster compute times matter as much, such as the need for JavaScript code for lighter coding tasks for mobile and Web application applications.

“In-browser, I think the biggest boon of WebAssembly is the potential to use libraries from other languages. Performance is good and can be helpful for web applications like Figma. But code reuse is broadly applicable to many web applications,” Butcher said.

“For the browser ecosystem, I don’t think we will see WebAssembly move beyond its assistive nature, and it will provide add-on advantages to JavaScript, not displace JavaScript,” he said. “WebAssembly’s real potential lies beyond the browser, where its security sandbox, performance profile and ease of development make it a perfect fit for innovation in the cloud.”

Since JavaScript is a language that is accessible to almost anyone and offers lots of community-supported libraries that “support tons of use cases without the need to reinvent the wheel,” Volk noted. “The fact that Wasm can be combined with ReactJS and other popular JavaScript frameworks further widens the range of use cases for JavaScript by allowing developers to deliver full-blown enterprise apps in a simple and responsive manner,” Volk said.

Security Stuff

Wasm offers security advantages compared to code deployed only in JavaScript. Wasm serves to make JavaScript code more secure when Wasm is used as a “compiler on steroids” with which JavaScript applications can be deployed. Wasm, for example, isolates JavaScript from the browser, ensures memory safety, and implements strongly typed variables that are harder to exploit compared to JavaScript’s dynamically typed ones. “All in all, running JavaScript on Wasm provides a nice ‘security upgrade’ for the overall app,” Volk said.

Indeed, Wasm offers security advantages on a number of fronts. This is because, as Sounil Yu, chief information security officer at JupiterOne, a provider of cyber asset management and governance solutions, communicated:

• Wasm as a compiler for JavaScript can improve the security of the application by reducing the vulnerability attack surface, providing better memory safety, obscuring the code, sandboxing the execution environment and leveraging an existing security ecosystem. Wasm has a limited set of instructions and better memory management, which helps reduce the attack surface for vulnerabilities and prevents some common types of vulnerabilities such as buffer overflows.
• Wasm code offers a bit of security through obscurity by not being human-readable, making it harder for attackers to reverse-engineer the code and thus more difficult to discover and exploit vulnerabilities.
• Wasm can also be run in a sandboxed environment, which can help to isolate the code from the rest of the system to prevent it from accessing sensitive information or performing illegal operations.
• Wasm Frameworks, like CNCF’s wasmCloud, extend the Wasm security footprint further by providing higher-level abstractions, reducing the amount of code that developers embed in each application. wasmCloud also eases the security burden for developers by making it easier to sign artifacts, enable built-in monitoring, and automate the patching of applications.

But let’s not say JavaScript is inherently insecure. In fact, Javascript “can be made quite secure,” Ralph Squillace, a principal program manager for Microsoft, Azure Core Upstream, said in an email response. “Browsers are some of the most attacked surfaces on the planet. WebAssembly, however, makes it easier to defend in depth with a mathematically provable sandbox model, which tools like Veriwasm take advantage of,” Squillace.

“In addition, you can use the upcoming component model to constrain the attack surface — the host might, for example, not even offer a file system API — and in the coming world these kinds of constraints will prove critical,” Squillace said. “But don’t be fooled: hosts can still make config mistakes and give too much power to a module!”

BC Gain’s obsession with computers began when he hacked a Space Invaders console to play all day for 25 cents at the local video arcade in the early 1980s. He then started writing code for very elementary games on the...

Read more from B. Cameron Gain