WebAssembly

WebAssembly is arguably beginning to live up to its hype. Although whether it realizes its potential or not remains to be seen and its ultimate success largely depends on factors beyond its worth as a technology. Things that could hold it back include a lack of agreement about standardization devices on which it is deployed.

Already, WebAssembly (aka Wasm) has been shown to work exceedingly well in the browser. It is widely used as a way to improve speed and security, and especially computing simplicity for applications that run directly in the browser, notably with JavaScript, as well as other languages. This speed and simplicity are eventually thanks to its binary computing structure that runs directly in a very clean way on the CPU.

WebAssembly is expected to eventually see wide-scale use as a way to deploy applications in a single module across different containers and Kubernetes clusters, devices (such as for edge and IoT devices) and multicloud environments simultaneously.

Other things that WebAssembly offers, given its low computing instruction-set size, are its ultrafast speeds and its security aspect — or its sandbox design to use industry jargon — since there is no access by other services or applications during deployments as the code inside remains isolated and is not accessible during its lightning fast journey measured in milliseconds for deployment across different environments.

WebAssembly is very suitable for serverless environments and is seen as a way to overcome many of serverless’ issues impeding its adoption. Today’s typical third-party use cases mean that serverless will require the support of a third party, which is more often than not a cloud vendor. For many, serverless architecture might be equated with Lambda on Amazon Web Services or an offering from another cloud vendor such as Azure, Google Cloud, Oracle or IBM. The organization thus must be content to entrust its several infrastructures not with multiple vendors, but with one third-party cloud provider, to administer its critical apps in many cases. For this reason alone, the avoidance of vendor lock-in is a key Wasm selling point.

“One of the things that we at Fermyon hear all the time is that developers love the serverless functions paradigm,” Matt Butcher, co-founder and CEO of Fermyon Technologies, said. “That statement almost always comes with a ‘but,’ though: While the big clouds each provide serverless, developers dislike the vendor lock-in, performance, and developer experience accompanying those offerings.”

An essential feature of Wasm is how it allows developers to no longer concern themselves with working with a potential multitude of libraries in order for their code to see deployment. “WebAssembly offers the promise of sharing libraries regardless of the underlying language. For example, a JavaScript program can load a library originally written in Python, and another written in Rust, and use them both,” Butcher said. “In today’s language ecosystem, every programming language has its own YAML parser, its own JPEG library, and so on. How many hours, days, and months are wasted implementing the same algorithms in a plethora of languages? WebAssembly is the remedy.”

Indeed, WebAssembly has the potential to become the new standard for composing apps, consisting of “truly universal building blocks” that can be combined and molded into many different apps, Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. For the developer, this is accomplished “without worrying about getting it to work within these apps’ runtimes. This opens the door for a massive jump in developer productivity, as developers could pick and choose from a library of boilerplate modules that could even be available as part of the runtime,” Volk said. “They could consist of microservices for identity management, access control, app messaging, data storage, and data mining or they could be entire data pipelines, machine learning models, or API integrations. This prospect of developers becoming laser-focused on writing business code, and business code only, is what makes Wasm so exciting.”

However, again, WebAssembly, as it stands now, remains a work in progress. Among other things, it is in the wait of the standardization of component interface Wasi, the layer required to ensure endpoint compatibility among the different devices and servers on which Wasm applications are deployed.

What Does WebAssembly Really Do?

The idea is that WebAssembly is designed to deploy applications written in the language of the developer’s choice for deployment anywhere simultaneously in disparate and various environments. “Disparate” since WebAssembly runs on a CPU and only requires a device, server, etc., to be able to run a CPU instruction set. This means that a single deployment of an application in a WebAssembly module theoretically should be able to run and be updated on a multitude of different disparate devices whether that might be for servers, edge devices, multiclouds, serverless environments, etc.

Anywhere there is a CPU capable of running instruction sets, WebAssembly is designed to run applications written in a growing number of languages it can host in a module. It now accommodates Python, JavaScript, C++, Rust and others. Different applications written with different programming languages should be able to function within a single module, although this capability largely remains under development. Essentially, a microservices-packed module should be able to be used to deploy multiple services across multiple disparate environments and to offer application updates without reconfiguring the endpoints. In theory, it is just a matter of configuring the application in the module so that each environment in which the module is deployed does not have to be reconfigured separately once the work is done inside the module.

Can WebAssembly Replace Containers?

The argument that WebAssembly will replace containers and Kubernetes is largely a non sequitur. This is because WebAssembly and containers and Kubernetes are different, yet important technologies. And even though there are some overlapping purposes, they also meet specific and separate computing needs.

At least in the immediate future, many organizations will be loath to replace their container infrastructure and Kubernetes environments. Besides likely losing their investments in those by replacing them with WebAssembly, WebAssembly is not a replace-all technology for all containerized environments. In fact, there is much attention paid these days to use Wasm to deploy applications on containers and in Kubernetes environments.

Docker continues to make announcements about how it will accommodate and extend support for WebAssembly. How both will work together and especially how Docker is used with containers to allow for them to deploy and manage applications with WebAssembly were often discussed. These adaptations are largely seen as necessary to pave the way for Wasm’s adoption and use with containers and Kubernetes.

“With supersonic startup speed and light runtime requirements, Wasm is well suited for serverless functions – something that has historically been hard to implement well in Docker. Conversely, Docker’s standout feature is its ability to easily bundle up a long-running server and its environment in a portable fashion,” Butcher said. “Long-running servers are not yet Wasm’s strong suit. Now that Wasm can be packaged in the same image format as a container, we’ll see the two technologies combined to build the kind of hybrid serverless-and-server microservice apps that have been difficult to achieve with prior technologies.”

Is WebAssembly Faster Than JavaScript?

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 — 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.

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.

JavaScript is a language that is accessible to almost anyone and offers lots of community-supported libraries that support many use cases without the need to reinvent the wheel each time, Volk noted. “Executing otherwise interpreter-dependent languages like JavaScript and Python as bytecode and separating out boilerplate code from the core application, could bring tremendous performance and capacity advantages,” Volk said.

Will WebAssembly Replace JavaScript?

The point is not if WebAssembly will replace JavaScript, because there are no foreseeable reasons why it might. What WebAssembly will do instead is extend the reach of JavaScript to make it more deployable beyond just the browser.

“What we’re seeing in Fermyon surprised us. Developers are clamoring to execute JavaScript and TypeScript in WebAssembly. What we hear from our community is that the serverless paradigm is what they love, and JavaScript is just one of a variety of languages they want to have on hand when building serverless functions,” Butcher said. “So, if Wasm was originally a supplement to JavaScript, in some ways the relationship has inverted.”

Does WebAssembly Offer Superior Security?

Wasm can offer 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.

“Wasm’s security model could enable the vast JavaScript community to start creating complete apps, instead of building out only frontends and relying on backend developers to do the rest,” Volk said. “The ability to chain together individual Wasm modules into basic apps that bring life to traditional JavaScript frontends is an exciting perspective. Imagine the possibilities if frontend developers could securely store and access data on and from MongoDB, Postgres or the SalesForce API.”

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,” he said.

“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!”