WebAssembly launched with a clear pitch: near-native performance for code running inside the browser, so heavy computation didn't have to be a JavaScript-shaped compromise. That pitch was true, and mostly beside the point of where Wasm ended up mattering most.
The part nobody was pitching
Outside the browser, Wasm turned out to solve a problem that had nothing to do with browsers at all: running untrusted code safely and portably, without shipping a full container for it. A Wasm module is sandboxed by default, starts in milliseconds instead of the seconds a container image takes to cold-start, and runs identically regardless of the host OS or CPU architecture underneath it.
That combination is exactly what a few unglamorous but very real problems needed:
- Plugin systems. Instead of loading arbitrary native code (a security nightmare) or shelling out to a subprocess (slow, heavyweight), an application can run user-submitted Wasm modules with a real sandbox boundary and predictable resource limits.
- Edge compute. Providers running functions across hundreds of locations care enormously about cold-start time. A Wasm module starting in single-digit milliseconds changes what's practical to run at the edge compared to a container that takes a second or more to spin up.
- Polyglot extensibility. A Wasm module can be compiled from Rust, C, Go, or a dozen other languages, and the host doesn't need to know which. That's a genuinely hard problem to solve any other way without picking a single embedded scripting language and living with its limitations.
Why this snuck up on people
None of this was the headline feature when Wasm shipped. It was framed as "fast code in the browser," and for a few years that's the only place people looked for it. The server-side story needed WASI (the WebAssembly System Interface) to mature enough to give Wasm modules a standard way to talk to files, networking, and the outside world — without that, a sandboxed module with no I/O story is a neat toy, not infrastructure.
Where this actually matters
If you're evaluating Wasm today, the browser use case is still real but narrower than the pitch suggested — most apps don't have a computation bottleneck that justifies the complexity. The server-side and edge use cases are where the sandboxing and startup-time properties solve problems that were previously expensive to solve well. It's a rare case of a technology's second use case turning out to be more consequential than the one it was actually built for.
