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

How WebAssembly Gets Used: The 18 Most Exciting Startups Building with Wasm - Amplify

As with any emerging technology, half of the early battle is figuring out how and why to use a technology. I'm hoping this post gives developers more insight into how Wasm is being used day to day and helps them make technical choices down the road.

amplifypartners.com

The rise of WebAssembly

In just four short years, WebAssembly has broken free of its origins as a useful browser-based technology and now powers some of the world's most complex distributed applications, from streaming platforms like Disney+ to e-commerce powerhouse Shopify. WebAssembly, or WASM for short, was developed by the World Wide Web Consortium (W3C) and first published in 2018.

www.infoworld.com

A cartoon intro to WebAssembly - Mozilla Hacks - the Web developer blog

WebAssembly is fast. You've probably heard this. But what is it that makes WebAssembly fast? In this series, I want to explain to you why WebAssembly is fast. WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser.

hacks.mozilla.org

How WebAssembly changes software distribution | Max Desiatov

Thanks to the open nature of the whole stack WebAssembly is arguably much closer to "write once, run anywhere" than Java/JVM ever was.

desiatov.com

The Scale to Zero Problem

Cloud is expensive. One reason for this is that a typical application instance sits idly waiting for inbound requests. Yet even though it is idle, it is incurring cloud charges. What if there was a way to scale down your application when it was not being used?

www.fermyon.com

Published on August 21, 2022.