WASI 0.3 • Hacker News Board

Re: WASI 0.3

#71

Post by yoshuaw » Fri, Jun 12, 2026, 5:23 PM UTC

dang wrote: post #70

yoshuaw wrote: post #59

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.

Ok, I've swapped that link in at the top and put the submitted URL ( https://github.com/WebAssembly/WASI/releases/tag/v0.3.0 ) in the toptext.

Thank you!

Re: WASI 0.3

#72

Post by airstrike » Fri, Jun 12, 2026, 5:38 PM UTC

tete wrote: post #62

spankalee wrote: post #57

Earlier quoted context omitted.

The speaker is right. Why should "system" interfaces and interfaces from other components ever be fundamentally different?

I get that. That's not my criticism. My criticism is that you can do say that about many things. With that argument you can essentially encompass everything, which is cool in a way, but also means that the scope is at least bigger than the original - hence what the speaker says. What I worry about here is that when I think about implementing it the scope will likely grow as well. And while I very much get the wish to…

So join the community and be the change you want to see in the world?

Re: WASI 0.3

#73

Post by mmastrac » Fri, Jun 12, 2026, 5:42 PM UTC

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.

Re: WASI 0.3

#74

Post by tekne » Fri, Jun 12, 2026, 6:01 PM UTC

Dwedit wrote: post #51

throawayonthe wrote: post #41

Earlier quoted context omitted.

it is faster, but there is unacceptable loss when passing data to/from js, definitely an area needing improvement (or having to do it less) https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Just allowing more than one arraybuffer could go a long way to help with performance. One array buffer for the wasm memory space, then an arraybuffer for each input or output argument.

Wasm multiple memories is a thing now

Re: WASI 0.3

#75

Post by azakai » Fri, Jun 12, 2026, 6:04 PM UTC

garganzol wrote: post #18

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 ma…

> Let's keep WebAssembly lean and fast!

Note that wasm is still lean and fast - WASI is not part of core wasm, but layered on top.

That is, it is possible to implement wasm without WASI. That is also true for other wasm proposals like WasmGC. It is very possible that parts of the ecosystem will not implement certain proposals if they don't make sense there (e.g. parts of the embedded ecosystem may never add GC, etc.).

Re: WASI 0.3

#76

Post by IshKebab » Fri, Jun 12, 2026, 6:12 PM UTC

iqihs wrote: post #38

IshKebab wrote: post #32

Earlier quoted context omitted.

I disagree. We shouldn't just be copying Unix until the end of time.

less copying and more keeping in the spirit of, as it has clearly shown it is a model that is built to last

It clearly hasn't, if you've been paying any attention to security. The Unix security model is that all code that a user runs is 100% trusted. That's absurd in today's world.

Re: WASI 0.3

#77

Post by WalterGR » Fri, Jun 12, 2026, 6:24 PM UTC

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

Re: WASI 0.3

#78

Post by hmry » Fri, Jun 12, 2026, 6:35 PM UTC

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.

Re: WASI 0.3

#79

Post by syrusakbary » Fri, Jun 12, 2026, 6:48 PM UTC

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.

Re: WASI 0.3

#80

Post by phickey » Fri, Jun 12, 2026, 7:03 PM UTC

hmry wrote: post #78

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.

No, the stack switching proposal is not used. Stack switching is a set of core Wasm opcodes that permit a guest to change its own stack. Instead of using opcodes inside the Wasm, the stackful async mode of the component model’s ABI calls out into the component model implementation where it can manipulate the stacks with special host powers - JSPI is sufficient on web engines to express this, and wasmtime manages guest stacks in memory.

When stack switching becomes available in all engines, it will be possible to implement this part of the component model in pure Wasm without host magic, e.g. web engines will be able to avoid the call out to JS to use JSPI.