Intro to WebAssembly

Author's note: Recurse Center blog posts condensed into a writing sample.

To quote Lin Clark, WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser. While this breaks JavaScript's 'monopoly', we expect developers to use both WebAssembly and JavaScript in the same application.

WebAssembly fulfils Java's founding promise of "write once run anywhere", with the JVM swapped out by the browser. Running the code in the browser effectively means the compiled .wasm binary is agnostic to the choice of processor and OS.

Why bother?

The first advantage is portability. Existing codebases can be compiled to WebAssembly to be run in the browser. The compiler tool chain with the most support for WebAssembly is LLVM; this benefits languages like C/C++ and Rust. In addition, these 'system languages' have smaller runtimes which in turn compile to smaller .wasm binaries.

The second advantage is speed. Compared to JavaScript, WebAssembly is closer to machine code and has gone through an optimization stage. Furthermore, there is no need for type inference reoptimization since WebAssembly has types. Fetching WebAssembly takes less time because it is more compact than JavaScript, as noted by Figma in a real-world use case.

Cool! What's the catch?

Like all new technologies, WebAssembly can be rough around the edges. WebAssembly supports only ints and floats natively, so relies on JavaScript for string support. For the moment WebAssembly also has no direct access to the DOM. The back-and-forth overhead between WebAssembly and JavaScript can add up, to varying degrees depending on the browser.

It's worth noting how loading .wasm binaries has to be done via JavaScript since cross-scripting rules in the browser blocks reads to the file system. Changes to allow direct loading are in the works, which would make WebAssembly interop more seamless.

Finally, WebAssembly doesn't know how to interact with garbage collectors. Once work to expose bindings to the JavaScript garbage collector is complete, garbage-collected languages can more readily be cross-compiled to .wasm binaries.

Got it. Anything else?

The WebAssembly project has now expanded beyond the browser, with wasmtime as an independent runtime and WASI as the unified systems interface. This could also make .wasm format the new standard in portable binaries, replacing .dylib/.so/.dll files for cross-language bridges.

One wonders, more broadly, if the technology will further consolidate the dominance that large tech companies have, or will a thousand startups bloom? Will there be a lot of end users who like it, but very few love? What will the killer app be, or for that matter, will there actually be one? Only time will tell, but we're excited to find out!

This post is a condensed 1-pager from the series

The series builds on Lin Clark's excellent intros

For minimal examples on compiling and running WebAssembly

To speed up Python with Rust via WebAssembly bridge