WebAssembly: the unifying future of computing?

A story about the possible future of web applications

Imagine powerful web applications running with the same fluidity and speed as native apps. With WebAssembly, this vision is becoming a reality.

WebAssembly (WASM) is a low-level assembly-like bytecode format for the web, supported as a compilation target by multiple languages, that runs at near native performance. It was first released in 2017, adopted as a World Wide Web Consortium (W3C) standard in 2019, and is today supported by all modern browsers. It aims to bring first class support for languages beyond JavaScript to the browser, and has already been adopted by the industry to bring powerful applications such as Figma and Adobe Photoshop to the web.

Humble Beginnings

In Tim Berners-Lee’s first proposal for the World Wide Web from 1989 it is described as a “hypertext project”. It would combine computer technology with data networks and hypertext to create a global information system accessible through the internet and web browsers.

Its original goal was to simplify knowledge sharing and enable easier collaboration between researchers across the world, and as the technology was further developed, the static text documents evolved into dynamic websites. By connecting to backend services, they gained the ability to render continuously updated content such as the latest news and weather forecasts, and with JavaScript they gained user interactivity and responsiveness.

JavaScript as a standard for Web

Not unlike the web itself, JavaScript has also gone above and beyond its original purpose. Combined with various frontend frameworks, it has transformed websites from interactive text documents into powerful web applications with capabilities rivaling those of natively running programs.

At this point the vast majority of everything we do on computers can be, and is done, inside of a web browser, and the web has become the most ubiquitous platform for end user applications.

By historical accident, JavaScript is the only natively supported programming language on the Web.

— Bringing the web up to speed with WebAssembly, Haas et. al. 2017

The benefits of targeting the web when developing and deploying an application are fairly obvious:

• Since the web is built on common, open standards, there is only a single build target. Developers need not take into consideration all possible operating systems and CPU architectures etc. of the end users, it only needs to run in a browser.
• Likewise, end users don’t need to bother with any installation or setup on their side, as long as their device has an (up to date) browser installed they are good to go.
• It is easy to iterate on the software, and push updates and fixes in an agile way.

On the other hand, the drawback used to be that the application would have to be implemented in JavaScript. For one, this can in principle lead to performance loss compared to a native application written in a lower level language such as C or Rust. However, modern JavaScript runtimes utilizing JIT compilation have become quite performant. Still, it remains a fact that JavaScript initially was designed to provide simple interactivity and animations, and for certain use cases there will be better suited tools, especially for computationally heavy workloads. Furthermore, for developers wanting to migrate their existing native applications to the web, it would be a huge amount of work to rewrite everything in JavaScript!

WebAssembly’s Answer

WebAssembly aims to address this issue by bringing first class support for multiple languages to web browsers.

It does so by providing a virtual machine (VM) with a low level assembly-like language which can serve as a common compilation target for multiple high level languages. The VM can then be implemented into web browsers to provide a WebAssembly runtime environment in addition to the JavaScript runtime. Then any language that supports WebAssembly as a compilation target becomes a first class language for targeting the browsers! As of today, all modern browsers has support for WebAssembly and many languages including C, C++ and Rust support WebAssembly as a compilation target.

At some level the WebAssembly can be thought of as a second take on the Java Virtual Machine (JVM), but designed with browsers and multiple languages in mind from the start. Compared to the JVM, WebAssembly makes fewer assumptions about the source code and is smaller in size. Since it is designed to run in the browser, WebAssembly is also sandboxed with no built in system calls capability, and it has small compiled binaries and fast startup for low latency.

WASM + WASI: Beyond Browsers

The JVM however was not originally designed to run code in web browsers, its purpose was to solve the issue of “it runs on my machine ¯\_(ツ)_/¯” by providing a layer of abstraction above CPU vendor specific assembly languages and so on. As it turns out, from designing a similar solution for browsers, the resulting WebAssembly VM could also be a suitable solution outside of browsers and be a more general and potentially more performant alternative to the JVM. To run outside of the browser, WebAssembly modules would only need a way to make system calls and interact with the host system from within the sandboxed VM, which is what the WebAssembly System Interface (WASI) aims to solve.

With WASI, WebAssembly truly has the potential to become a unifying compilation target for all native platforms in addition to the web, as made clear by the above tweet from Docker founder Solomon Hykes. Compared to Docker, which essentially ships an application together with its required runtime environment, WebAssembly has the advantage of only shipping a small compiled binary resulting in lower transfer overhead and faster startup times.

On a final note it should also be mentioned that WebAssembly does not aim to replace JavaScript, nor is it likely to replace Docker. It is in fact designed to run alongside JavaScript, and the typical approach will likely be to do UI/UX and DOM interaction with JavaScript, and call on WebAssembly modules for more computationally intensive workloads. Similarly, Docker currently has WebAssembly containers as a beta feature, enabling running a WebAssembly application alongside “traditional” Linux containers.

Blurring the Lines Between Web and Native Applications

Modern JavaScript has blurred the line between applications running natively and on the web for end users. Webassembly can take this further and also do the same for developers and blur the traditional distinction between web development and application development. Being developed as an open standard means that things move more slowly compared to independent projects, but for true cross platform support, standards should be the way to go, and it will be exciting to see how WebAssembly will fit into the future of software development and computing.