WASI 0.3
Points and comments are a snapshot, not live.
WASI 0.3 standardizes async as a native primitive in WebAssembly Components, replacing workarounds from version 0.2.
The WASI Subgroup ratified WASI 0.3.0, rebasing the specification onto the WebAssembly Component Model's async primitives. Previously, each component required its own event loop; now the host manages a single shared event loop across all components. The new spec introduces stream<T>, future<T>, and async as first-class constructs in the canonical ABI. WASI 0.3 uses a completion-based async model similar to Linux io_uring and Windows IOCP, enabling components to be composed directly without network calls, reducing microservice latency from milliseconds to nanoseconds. Most interface changes from 0.2 to 0.3 are mechanical simplifications. Guest toolchains for Rust, Go, JavaScript, Python, and C are adding support. Wasmtime 46 will ship WASI 0.3.0 with Component Model async enabled by default.
What commenters are saying
Commenters disputed whether WebAssembly constitutes a meaningful breakthrough, with some noting silent adoption in Figma, Google Sheets, and video platforms, while skeptics argue it remains niche without paradigm-shifting impact. Plugin architectures and embedded use cases emerged as strong points, as did the ability to run arbitrary languages in sandboxed environments. One commenter raised concerns about development transparency, stating WASI work had appeared to stall for two years; a maintainer responded with links to public meetings, Zulip channels, conferences, and recorded keynotes documenting the effort. Debugging limitations were flagged as a friction point, though one respondent noted Wasmtime now supports remote debugging via LLDB. A technical concern surfaced about JS-to-WASM boundary overhead and performance parity.