The contract at the border
January 25, 2024, somewhere on a video call spanning at least three time zones, the WASI Subgroup voted. The motion was procedural — formally launching WASI 0.2 — but the implications were not. For the first time, a Rust library and a Go program could call each other without either side knowing a thing about the other’s memory layout, type system, or runtime.
WebAssembly was announced in 2015 by the four major browser vendors and standardized by the W3C in December 2019. The pitch was elegant: a compact binary format, sandboxed by construction, portable across every architecture. For computation in the browser, it was transformative. But a WebAssembly module was a sealed room — powerful inside, with no standardized doors.
On March 27, 2019, Mozilla engineer Lin Clark published “Standardizing WASI” on Mozilla Hacks, proposing a system interface to run WebAssembly outside the browser. Later that year, the Bytecode Alliance formed: Mozilla, Fastly, Intel, and others, committing to the non-browser ecosystem together. WASI Preview 1 gave modules basic file and clock access — a stripped-down POSIX, enough to run a program, not enough to compose one. It was a foothold, not a foundation.
The problem was the C ABI. WASI Preview 1 used the C Application Binary Interface as the lingua franca between modules, which meant cross-language calls were brittle, pointer hazards were real, and any module that called another had to know too much about the caller’s memory layout. The Component Model changed the terms entirely. Instead of shared memory, it proposed typed interfaces — defined in WIT, the WebAssembly Interface Types language — that every language could target independently. The types live at the border; the memory stays private. A Rust component and a Python component negotiate at the interface, not inside each other’s house.
WASI 0.2 — voted on January 25, 2024, and celebrated at the Plumber’s Summit in Raleigh, North Carolina, one week later — is the first stable release built entirely on the Component Model. Its two initial “worlds” are wasi-cli (a modern POSIX analogue for command-line programs) and wasi-http (an HTTP proxy world). Wasmtime, the Bytecode Alliance’s own runtime, was the first major implementation with full support for both.
The most pointed reaction to the original WASI announcement came not from a standards body but from Solomon Hykes, the man who created Docker: “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is.” Hykes was not being modest. The entire containerisation movement — the thing that reshaped cloud infrastructure for a decade — was, he implied, a workaround for problems the Component Model now addresses directly. Isolation, portability, language neutrality: Docker solved them in 2013 with Linux namespaces and layered filesystems. WASM solves them in the instruction set.
Software has always struggled with the seam between components. Unix pipes were elegant but untyped. CORBA was typed but baroque. REST is typed if you trust the documentation and the documentation is current. The Component Model is typed at the interface boundary, sandboxed by capability, and portable across every language that compiles to WASM. When agentic systems began treating tools as composable units in 2024 and 2025, WASM components offered an answer: a bounded, language-neutral unit of trust, no shared address space required.
The sandbox is no longer a prison. It is a contract.
Sources
- WASI 0.2 Launched — Bytecode Alliance — Dan Gohman’s announcement of the January 25, 2024 vote and the Component Model’s intellectual foundation.
- Standardizing WASI — Mozilla Hacks — Lin Clark’s March 27, 2019 post proposing WASI and the portability and capability-security goals.
- Solomon Hykes on WASM+WASI — X — Docker creator’s March 2019 claim that WASM+WASI would have made Docker unnecessary.
- The WebAssembly Component Model — Bytecode Alliance — WIT, worlds, and the polyglot composability architecture.