What is it?
WebAssembly is a low-level assembly-like programming language designed to serve as a compilation target for higher-level languages like Rust, Python, C, C#, Swift, Go, and more.
Browsers know how to run WebAssembly code, and typically expect to run it alongside JavaScript — so the idea is that you write your Rust or Python modules, compile them to WebAssembly, and then call the compiled WebAssembly module from JavaScript.
Why is it useful?
First-order effects
From that description alone, there are a few obvious reasons why WebAssembly might be useful:
- Code sharing: libraries that we develop for the server, or for native desktop applications, can now be used directly in the browser-based web applications.
- Performance: WebAssembly code is designed to run at “near native” speeds, so applications that were once ‘too slow’ or ‘too performance intensive’ to run in the browser may now be free to do so. (Google Earth is one oft-cited an example here.) This is the result of ahead-of-time compilation (you compile your WebAssembly code in advance, unlike JavaScript, which is parsed and executed by the browser), static typing, and the intricacies of the design of the instruction set.
Improved code sharing has the potential to make it easier to build cross-platform applications, while improved performance has the potential to enable the development of applications that otherwise couldn’t have existed on the web at all (like a browser-native Google Earth).
Second-order effects
WebAssembly could have implications well beyond the browser. At the end of the day, WebAssembly is a programming language, whose code you execute on a “runtime”. Browsers know how to execute WebAssembly code, but you can run WebAssembly code on other “runtimes” too.
This is referred to as “portability”: the ability to compile code down to WebAssembly possibly spanning multiple different languages), thereby enabling it to run ~anywhere.
Imagine: you spin up a server, and want to run some Python code on it, plus some C# code, plus some other stuff. One way to do that is to install Python, install C#, and so on. But an alternative would be to install a WebAssembly runtime, compile your programs to WebAssembly, and run the WebAssembly code instead. Suddenly, you have a single runtime capable of executing code written in any programming language. (WebAssembly is also heavily sandboxed and designed with a focus on security, which makes it useful for running arbitrary and potentially-untrusted code.)
Cloudflare Workers is another proof-point for the value of portability. Workers began by supporting serverless JavaScript before expanding to WebAssembly. By supporting WebAssembly, Workers immediately supports Rust, Python, Go, etc.
(Aside: Made with WebAssembly is another good resource for understanding WebAssembly, and they highlight (1) performance and (2) portability as its key features. They frame WebAssembly as another piece in the web development toolkit: “HTML (Declaring UI), CSS (Styling UI), JavaScript (Adding functionality to a UI), and now WebAssembly (Processing heavy tasks, to give results back to the UI)”. They also have a bunch of other examples of WebAssembly in the wild (e.g., 1Password’s browser apps, Figma, and so on), though it’s clear from the list that WebAssembly is still very early.)
Why does it matter?
- WebAssembly could enable entirely new classes of applications to run in the browser.
- WebAssembly could usher in a new era for cross-platform development, making it easier to build native and web applications in concert.
- WebAssembly could make it easier to write code that runs anywhere (WASI — which is a standard, and not a tool or technology — is another thing to watch here).
- WebAssembly could enable platforms to run untrusted user code. For example, rather than using webhooks to react to events, why not provide whatever platform you’re using with the code you want to run when that event takes place? With WebAssembly, platforms can implement that paradigm. (You see this today with Auth0 hooks and others, but they’re mostly using JavaScript on V8 Isolates (presumedly).)
The other thing to think about here is that if WebAssembly is to play an important role in building applications, that would likely have knock-on effects with regards to the developer tools we use to build with WebAssembly. For example, if we’re building Python-based applications in the browser, how do we handle packaging?
What tools / companies have emerged around WebAssembly?
In no particular order, here are a few:
- Wasmer: A WebAssembly runtime
- WAPM: A package manager for WebAssembly
- Pyodide: A Python distribution for the browser, based on WebAssembly
- Fermyon: WebAssembly microservices platform
- Lunatic: Erlang-inspired WebAssembly runtime
- Starlane
- wasmcloud
- Suborbital
- Mycelial
Resources
Published on August 21, 2022.