WASI 0.3 ratified: async becomes native to WebAssembly Components

The WASI Subgroup has ratified WASI 0.3.0, a stable release that rebuilds the WebAssembly System Interface on top of the Component Model’s new native async primitives. The headline change: stream, future, and async functions are now first-class constructs in the canonical ABI rather than patterns bolted on via the wasi:io package. This eliminates the awkward start/finish/subscribe choreography of WASI 0.2 and lets the host runtime manage a single shared event loop, fixing a fundamental composition problem — under 0.2, each component ran its own event loop, so components using streaming or async APIs simply couldn’t be composed together. The new model is completion-based, in the spirit of io_uring and IOCP, with readiness-style APIs emulatable on top.

For toolchain authors, native async means bindings generators can emit idiomatic concurrency for each target language: async traits in Rust, stackless coroutines for Python, JavaScript, and C#, and goroutine-backed blocking calls in Go, where the runtime parks a goroutine at the ABI boundary and resumes it when data arrives. The interfaces also got practical fixes — streams now return a separate future carrying terminal status, so a reader that stops early can still distinguish a clean close from an error, something 0.2 couldn’t express.

The wasi:http interface saw the deepest rework, splitting into service and middleware worlds (the latter replacing 0.2’s proxy world) and enabling service chaining: composed components can call each other in-process instead of over the network, cutting inter-service call latency from milliseconds to nanoseconds. Wasmtime 45 already runs the release candidate, Wasmtime 46 will ship 0.3 with async on by default, and jco and language toolchains are expected to announce support in the coming months. For anyone betting on the Component Model as a server-side composition layer, this release removes its biggest architectural blocker.