WASI 0.3
mavdol04
240 points
90 comments
June 12, 2026
https://github.com/WebAssembly/WASI/releases/tag/v0.3.0
Related Discussions
Found 5 related stories in 103.9ms across 10,324 title embeddings via pgvector HNSW
- Wasi: WebGPU – A Proposed WebAssembly System Interface API giancarlostoro · 23 pts · June 12, 2026 · 63% similar
- Wisp: WebAssembly Lisp DavidCanHelp · 15 pts · March 30, 2026 · 57% similar
- WebAssembly 3.0 tosh · 17 pts · June 10, 2026 · 57% similar
- Show HN: 2.7KB Zig WASM – live globe showing executions at 300 CF edges wolfejam · 20 pts · March 29, 2026 · 50% similar
- Watgo – A WebAssembly Toolkit for Go ibobev · 88 pts · April 10, 2026 · 49% similar
Discussion Highlights (12 comments)
shevy-java
Will WebAssembly ever achieve a real breakthrough? It's been almost 10 years since it came around. HTML, CSS and JavaScript were a breakthrough back in the days. WebAssembly still is not right now; only very few folks or companies use it.
b33j0r
Love/hate with this one. How was I supposed to follow this? I tried, and few things were publicly visible for nearly two years. I last checked in march and it looked like no progress had been made. That makes me very suspicious of wasiv3. Funny enough, I already implemented a bunch of the promises (pun not intended) and think that freestanding wasm with custom integrations is the more likely future. The promise of wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases. I do not like that this has been worked on in the shadows.
lifty
If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
simonw
If you don't want to download the .tar.gz I think you can browse the content for this release (.wit interface files) here on GitHub: https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals
garganzol
Wrong direction. 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 that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its main purpose of providing easy interoperability between different ecosystems is totally lost. I do not know why WebAssembly committee thinks that shoving-in CORBA-like monstrosity is even an acceptable idea. Let's keep WebAssembly lean and fast! Anything extra can (and should) be implemented by other technologies.
ilaksh
Is there some Zig code demonstrating how to use all the changes in a Zig program that compiles to WASI 0.3.0?
yoshuaw
Hey everyone, we just published the announcement post for WASI 0.3 on the Bytecode Alliance blog: https://bytecodealliance.org/articles/WASI-0.3 The current link is just the release notes and covers only the interface-level changes. The announcement post goes into more detail on what's new in WASI 0.3, how it differs from WASI 0.2, and includes examples.
_jsdw
This is funny timing to me, because just the other week I did a dive into WebAssembly and WASI 0.2 ( https://jsdw.me/posts/wasm-components/ ) and assumed that 0.3 would be a while yet as there was no obvious (to me) sign it would come for a while! Once the tooling is there and Rust has a wasi 0.3 target I'll give it more of a look at :)
mmastrac
I'd love it if WASI modules could introspect their own custom sections (potentially even more introspection than that), but I've never been able to figure out a good way to do this. Seems like a fairly useful feature for a few use cases.
WalterGR
Also see, from yesterday: https://news.ycombinator.com/item?id=48448083 “The Road to the WASM Component Model 1.0” (bytecodealliance.org) 95 points | by emschwartz | 99 comments
hmry
Does the stackfull async implementation use the stack-switching proposal? I was under the impression that it's not implemented in most runtimes (very difficult to retrofit into existing implementations), and only available on x86_64 Linux in wasmtime.
syrusakbary
Congrats on the release to the WASI team. TL;DR: WASI 0.3.0 is the Component Model-based WASI proposal. It adds async/await-style capabilities such as actors and streams, and 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 and runtimes that supported it. If your goal is to compile existing, unmodified C/C++ programs and libraries to WebAssembly, WASIX may be a more practical option today ( https://wasix.org/ ). Disclosure: I’m part of Wasmer, the company behind WASIX.