WASI 0.3 lands native async — and one runtime, no browser, breaks the old WASI again
After two near-silent years, WASI 0.3 shipped on June 11, 2026 with first-class async baked into the Component Model. The host now owns one shared event loop. The Wasmer CEO showed up to note it runs in exactly one server-side runtime and still breaks the original WASI.
WASI 0.3, ratified June 11, replaces the old polling primitives with first-class stream<T>, future<T> and async functions, moving to completion-based scheduling like io_uring. One event loop, managed by the host, is shared by all components.
The Wasmer CEO's reality check in the thread: it runs in one server-side runtime, no browser support, and it again breaks compatibility with the original WASI — and a decade in, skeptics still ask whether WebAssembly has had its breakthrough.
WASI finally gets async — by handing the event loop to the host
The Bytecode Alliance's announcement marks WASI 0.3 as ratified on June 11, 2026. The headline change is native asynchrony folded directly into the WebAssembly Component Model. Where WASI 0.2 made each component juggle its own event loop, now "the host is the one in charge of managing the one event loop that is shared by all components."
Concretely, the old resource-based primitives are replaced by first-class constructs:
| WASI 0.2 | WASI 0.3 |
|---|---|
resource pollable |
future<T> |
resource input-stream |
stream<u8> |
start-foo / finish-foo |
foo: async func(...) |
Scheduling moves from readiness-based polling to a completion-based model, the same shape as Linux io_uring. Rust uses async fn; Go parks goroutines at ABI boundaries. The author confirmed the framing in the thread, noting the announcement post — not just the release notes — is where the examples and 0.2-vs-0.3 diff live.
The Wasmer CEO's reality check
The most grounding comment came from a vendor with skin in the game:
"WASI 0.3.0 is the Component Model-based WASI proposal… today is runnable in only one server-side Wasm runtime (it is not supported natively by browsers). Unfortunately it still breaks compatibility with the original WASI proposal… If your goal is to compile existing, unmodified C/C++ programs and libraries to WebAssembly, WASIX may be a more practical option today." — Wasmer's founder and CEO
That compatibility break is a recurring sore point. One reader argued the project had drifted from its founding idea:
"WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication… I do not know why WebAssembly committee thinks that shoving-in CORBA-like monstrosity is even an acceptable idea." — a developer in the thread
The decade-old question, still unanswered
Simon Willison flagged that you can browse the .wit interface files directly on GitHub instead of downloading the release tarball. But the thread kept circling back to adoption.
"Will WebAssembly ever achieve a real breakthrough? It's been almost 10 years since it came around… WebAssembly still is not right now; only very few folks or companies use it." — a long-time commenter on the breakthrough that hasn't come
The Component Model's pitch is real: "direct composition" of services, cutting cross-component latency from milliseconds toward nanoseconds. The catch is just as real: it runs in Wasmtime today, not browsers, and each WASI revision asks the ecosystem to migrate again. Async is the feature production WASM users have wanted for years. Whether they can use it depends on tooling — jco, Rust, Go, Python and C# targets are still rolling out 0.3 support.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
He hit 72 tokens/sec coding locally on a MacBook. The thread asked: why not just use Ollama?
A guide builds a fully local coding agent on an M1 Max: llama.cpp, Gemma 4, a speculative-decoding draft model for a 24% speedup. The top reply was a shrug — load Ollama, point your agent at it, skip all this.