WebAssembly and WASI

**WebAssembly (Wasm)** is a portable, low-level binary instruction format designed as a compilation target for languages like C, C++, Rust, Go, and Zig. It was standardised as a W3C recommendation in December 2019. **WASI** (WebAssembly System Interface) extends Wasm beyond browsers by defining a capability-based interface to operating system services — filesystem, networking, clocks, randomness, environment. WASI 0.3 shipped in February 2026; WASI 1.0 is expected late 2026. ## Why it matters Wasm + WASI is the closest the industry has come to a real 'write once, run anywhere' target — the promise Java originally made and failed to deliver (write once, *debug* everywhere): - **Architecture-agnostic**: single binary runs unmodified on x86-64, ARM64, RISC-V, Wasm-native hardware, etc. - **Fast startup**: 1-5 ms cold start vs 50-500 ms for Docker containers, 100+ ms for JVM. - **Small size**: typical 2-10 MB module vs 100+ MB Docker image vs 150-300 MB Electron app. - **Strong sandbox**: memory-safe by construction, capability-based syscalls. - **Near-native performance**: AOT or JIT compilation closes most of the gap with native. - **Language interop via Component Model**: Rust + Python + JS in one module with typed interfaces. Docker founder Solomon Hykes: 'If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing.' ## Key engines - **Wasmtime** (Bytecode Alliance) — reference server-side runtime - **Wasmer** — commercial server runtime with language SDKs - **V8 / SpiderMonkey / JavaScriptCore** — browser engines - **WasmEdge** — CNCF project, edge-focused - **wazero** — zero-dependency Go runtime ## Use cases in 2026 - **Fastly Compute@Edge**: serverless functions in 30+ languages via Wasm. - **Cloudflare Workers**: Wasm for native-speed workloads alongside V8 isolates. - **Shopify**: third-party app extensions run as Wasm. - **Figma**: rendering engine compiled to Wasm. - **Adobe Photoshop on the web**: core engine as Wasm. - **Plugin systems**: Envoy filters, Kubernetes admission controllers, PostgreSQL extensions via pgx. ## Relationship to The Original 80KB Windows Task Manager Wasm + WASI enables per-target-optimized native compilation (an AOT or JIT engine picks best instructions for the actual hardware) from a single portable source. Combined with ML compilers and AI-driven code generation, this is the plausible near-term architecture for 'universal yet optimal' — a holy grail that simpler universal runtimes (JVM, .NET) failed to hit. ## Contrast with Cosmopolitan Libc Cosmopolitan Libc (Justine Tunney) solves the same 'one binary everywhere' problem at the **executable format** level — a single multi-format ELF/PE/Mach-O binary that runs natively on Linux/macOS/Windows/FreeBSD without any runtime. Wasm+WASI solves it at the **virtual-ISA** level with a runtime. Cosmopolitan gives native performance with no runtime; Wasm gives portability across hardware and sandboxing with a lightweight runtime. Both are valid answers to different parts of the portability puzzle.