WebAssembly's browser success story is established. The more interesting 2021 development is what happens when WASM runs outside the browser. WASI (WebAssembly System Interface) is making WASM a portable, sandboxed runtime for server-side workloads.
What WASI provides
WASI is a standard interface that allows WebAssembly modules to interact with the operating system, filesystem, clocks, random, network, in a portable and capability-safe way. A WASM module compiled with WASI can run on any WASI-compatible runtime (Wasmtime, Wasmer, WasmEdge) on any OS without recompilation. The capability model restricts what system resources the module can access: a module only gets the filesystem paths and network sockets it's explicitly granted.
The edge computing use case
Cloudflare Workers and Fastly Compute@Edge run WASM at edge locations globally. The isolation model of WASM (each module is sandboxed, starts in microseconds, uses minimal memory) is significantly more efficient than running a container per request. For short-lived, stateless compute at the edge, WASM provides a better cost and latency profile than any container-based approach.
The plugin architecture use case
WASM as a plugin runtime is a strong pattern: plugins compiled to WASM can be loaded by a host application, execute arbitrary logic, and be safely sandboxed from the host. Envoy Proxy uses WASM for its extension model. OPA (Open Policy Agent) can run WASM policies. The plugin author cannot crash the host or access resources the host does not grant, a stronger safety model than shared library plugins.
The language ecosystem
Rust has first-class WASM support and is the primary language for production WASM. Go supports WASM compilation with GOOS=wasip1 (added in Go 1.21)..NET supports WASM with Blazor WebAssembly and experimental WASI support. C/C++ compile to WASM via Emscripten. The Bytecode Alliance (Fastly, Mozilla, Intel, Microsoft) drives the WASI standardisation effort.