What Happened to WebAssembly

Summary

Table Of Contents On every WebAssembly discussion, there is inevitably one comment (often near the top) asking what happened. It seems to have been advertised as a world-changing advancement. Was it just oversold? Was it another JVM applet scenario, doomed to fail? I’d like to tackle this in a weirdly roundabout way because I think these sorts of questions make a few misplaced assumptions that are critical to clarify. In The Real World Of course, WebAssembly does see real-world usage. Let’s list some examples! For many of these, WebAssembly is critical to either their entire product or a major feature. But I think this alone is not very convincing. We don’t yet see major websites entirely built with webassembly-based frameworks. We’re not building our applications directly to WebAssembly for maximum portability. But why not? To answer this, we need a good mental model for what WebAssembly is. This will help us qualify where it is most impactful and the limitations we’re up against. What Is WebAssembly In a word, WebAssembly is a language. A Note On Speed This makes questions like “how fast is WebAssembly” a bit hard to answer. You don’t ask how fast algebraic notation is—it’s not a very sensible question. Taken in the context of something like JavaScript, the language is only as fast as the engine running it. JavaScript the language has no speed, but you can benchmark JS engines like V8, SpiderMonkey, and JavaScriptCore. You can benchmark the IO libraries of JS runtimes like Bun, Deno, and Node. What people actually mean is “how useful are the constructs of this language to efficient mappings of modern hardware” and “what is the current landscape of systems taking advantage of these constructs”. Through clever-enough engineering, you can make any system sufficiently fast with some trade-offs. If compiling your code directly to C doesn’t bother you, getting “near native” speeds is possible in both JavaScript and WebAssembly. That’s right, you can compile WebAssembly!...