Table of contents
This post is a summary of our livestream where Flaki took me on a tour of the WebAssembly ecosystem. Thank you, Flaki!
WebAssembly (or Wasm for short) is significant for a number of reasons. One of the factors that makes it a compelling technology is how it, as a standard, came from and has developed by a committee, and how its ecosystem(s) has evolved from that philosophy. In this discussion, we took a look at the ecosystem itself and pondered its future.
It starts: Running code on the web
One of the most well known uses for Wasm is its applications on the web, doing things like running DOS games in the browser (courtesy of Internet Archive) or image manipulation.
The Internet Archive’s use of DosBox lets folks play classic DOS games in the browser, powered by WebAssembly. This works by bringing the open-source DOS emulator DOSBox to the web.
But as the running gag goes: WebAssembly is neither Web, nor Assembly — that is, strictly speaking it’s not just a language like the Assembly programming language, but the definition of a virtual machine, and since its inception it has aspired well beyond the confines of the Web.
How did we get here?
WebAssembly has been constructed as a series of closely related, but separate standards, published on the official website for the technology. Individuals and organisations in the WebAssembly community such as the Bytecode Alliance are continuing to collaborate to maintain and further progress on these standards.
The Bytecode Alliance’s website, describing its dedication to open Wasm standards.
.wat
and binary
files
While several programming languages can be compiled to Wasm, that bytecode needs to be run in its own way, using Ahead-of-Time (AoT) or Just-in-Time (JiT) compilers, each having their advantages and disadvantages that are beyond the scope of this post where we will try to focus on the Wasm ecosystem. For further reading on JiT and other compilers, check out this helpful blog post!
However, what does WebAssembly look like on the filesystem or as code? Two used formats are the binary .wasm
file format and the .wat
WebAssembly Text format. Both are equivalent as target representations of source code written from other languages intended to be used as WebAssembly. That said, although both can be compiled to machine-native bytecode, .wasm
binaries can also be directly executed in most runtimes. The other difference between the two is that .wat
has the benefit of being more easily human-readable. Playgrounds such as WasmFiddle allow us to view both representations in the browser and inspect what our Wasm output files look like:
WasmFiddle showing a C program that returns the number 42 being compiled to Wat format.
Possibilities built upon standards
A more recent, significant extension is the WebAssembly System Interface, or WASI standard. As the website describes, its big focus is security and portability of programs running in WASI, which are designed to be run independently of Web APIs, JavaScript, or the browser. This unshackling from the browser has huge implications for where Wasm is going next.
Code re-usability
Being able to bundle modules into a Wasm binary that can be shared across different applications, such as libSquoosh being used in different applications that do image manipulations, or even different versions of the same application, such as Google Earth being on both the desktop and the web.
Part of the Squoosh app, libSquoosh is available as a single integration for JavaScript apps.
Google Earth, written in C++, running in the browser with the same code that runs it on the desktop.
Containerization: Wasm on the Server
Having the platform-independent WebAssembly bytecode that applications and their dependencies can be built into helps with their portability.
This has opened the door to what is one of the latest and most exciting developments of WebAssembly: Running on a server. This is being done at places like Shopify to extend their apps, Cloudflare Workers enabling the deployment of serverless code, and our very own open-source cloud native WebAssembly framework, Atmo.
CloudFlare Workers’ website, boasting their ability to ship small pieces of runnable code.
Extensibility and safety
WebAssembly’s sandbox-first approach to computing allows users to create extensible and safe environments where folks can develop plugins and extensions to their favourite applications without compromising on safety, such as with Figma’s plugin system.
With the power of WASI however, we’re not just limited to the browser. On the desktop side, Wasm is also very capable! For example, the terminal multiplexing tool Zellij boasts the ability to have plugins that run on WebAssembly.
Zellij’s user docs, describing the plugin system.
Beyond the browser and desktop
The safety and extensibility offered by Wasm goes beyond even the browser and desktop, as it can be very useful in the cloud as well.
At Suborbital, we’re leveraging server-side Wasm by allowing folks to extend their SaaS applications to offer serverless functions and harness the full extensibility and performance advantages of WebAssembly.
This is also something that Shopify does with their app store, providing developers the ability to develop third party applications that interact directly with Shopify, executing within Shopify’s infrastructure to reduce latency when compared to self-hosted applications, and at the same time leveraging the safety of WebAssembly.
With Containerization comes Edge computing
WebAssembly’s principles translate smoothly into edge computing use-cases, that is, complex code executions closer to the clients who make requests to a service. Wasm binaries can be easily built and deployed to edge nodes, and they are able to run efficiently in these less powerful environments.
Different applications for edge computing include server-side rendering (SSR) for complex web applications and serverless SaaS functions. By using WebAssembly, we can in turn leverage its security, its portability, and also give folks the opportunity to write in familiar programming languages that compile to Wasm targets.
https://en.wikipedia.org/wiki/Edge_computing#/media/File:Edge_computing_infrastructure.png.
So why use this over, say, something like virtual machines? The difference comes in the sandbox factor, outlined previously. Whereas VMs require locking down kernel spaces in a piecemeal fashion, with Wasm this is handled as a "deny-by-default” system, leaving us as developers or administrators to explicitly define which WASI or other WebAssembly permissions to enable.
Having these fast-to-initialize, memory efficient, secure Wasm binaries allows us to run these minuscule process-like computations in a matter of micro, not milli, -seconds.
Fastly’s Compute@Edge platform.
What does the future hold?
One of the most exciting developments in WebAssembly comes in the form of nanoprocess model. By standardising the interfaces between individual Wasm modules (independent of the programming languages the modules were originally written in), we can compose complex applications from WebAssembly modules linked in a lightweight fashion, improving security, reusability and further boosting development velocity.
Wasm nanoprocesses as shown in https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/
This kind of micro-process model will definitely be worth keeping an eye on! It, along with other extensions to the specification and their implementations will continue to push the WebAssembly ecosystem forward, and we’re eager to see where this goes.
And hey, why not end on something fun? If we can run DOS games in the browser, can that concept be turned up to 11, like say, running an entire computer architecture in a browser?
Windows 98 with Solitaire running in the browser: https://copy.sh/v86/?profile=windows98.
Turns out that yes, it can. Here, we’re not just running a DOS emulator, but simulating the entire architecture of a computer running Windows 98 in WebAssembly. How cool!