FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
72% Positive
Analyzed from 3270 words in the discussion.
Trending Topics
#wasi#wasm#webassembly#component#model#https#more#languages#blocking#something
Discussion (62 Comments)Read Original on HackerNews
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.
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.
- Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events...
- A dedicated Zulip: https://bytecodealliance.zulipchat.com/
- Conferences organized around exactly these topics: Wasm Day, WasmCon, Wasm I/O, and the Bytecode Alliance Plumbers Summit
- CNCF projects: wasmCloud, Spin
- Blogs, many with recordings, summaries, and transcripts: https://bytecodealliance.org/articles/the-road-to-component-..., https://wasmcloud.com/community/, https://spinframework.dev/blog/index
If you want the architectural direction straight from the source, Luke Wagner's keynotes are the best place to start:
- "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4
- "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE
- "Towards a Component Model 1.0" (Wasm I/O 2026): https://www.youtube.com/watch?v=qq0Auw01tH8
I mean this, though - what else would you like to see to try and make the content and process more accessible? Are there communities that are doing this really well that we could use for inspiration?
At 18:00 the speaker states something like "It should not be Systems Interface but Standard Interfaces" which honestly sounds like a different project. As an implementer or even as just a user in general, can it be trusted that tomorrow it isn't something completely different? Seems like an odd standard to follow.
(EDIT and aside: Rereading this it reads more dismissive than I meant it. So if this isn't clear: I want WASI to succeed. I think having a widely used system interface is great, but I think many know standards that suffered from scope creep. And while big successful standards for better or for worse at least have a chance of surviving this, WASI as the 0.3 indicates is in its infancy. So I worry about it turning out bad, leading to people abandoning the idea altogether or the standard losing sight of its initial goal. So while this is criticism the only reason I bother to write it in first place is because I badly want it to succeed. I worry that if WASI tries to do too much at once - and I totally understand wanting to do that - it makes it less likely to be successfully implemented and thereby less likely to succeed as a standard.)
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.
If you have a host system where you want to expose APIs in an language-agnostic way, IDLs are the best way to do that.
You're also conflating the core WebAssembly work with the WASI work. There is some overlap in people, but WASI is developed separately.
I’ve written Wasm and component model wat extensively over the last decade to develop tests for Wasmtime, and even for an expert it’s a bad experience.
Wit syntax is easy to read and write by hand. There are high quality parsers that can transform it to and from the binary or wat format as needed, and code generators for a wide range of languages. It’s a way, way better experience in every way to deal with wit compared to the wat format.
Now it feels like it moved from "what would we need to get things done and achieve our goals?" to "what could be done and which goals could we achieve?"
Maybe I am missing something, but are the recent changes something that people requested?
Component model enable both using one thing.
The WASI standard is not at 1.0 yet! The people designing WASI are still trying to figure out what people want WASI to be at this point.
This is very likely to involve a lot of major reworking before 1.0, in response to feedback from orgs actually trying to implement WASI-based WebAssembly embeddings into their systems and runtimes. 0.1.x -> 0.2.x was one reworking; 0.2.x -> 0.3.x is another. There may be more of these before an approach is finally settled upon / "locked in" for 1.x.
---
> Let's keep WebAssembly lean and fast!
AFAICT, the entire point of the changes (incl. the more detailed component model) in WASI 0.3 is performance. Not performance of WebAssembly as a black box, though; but rather, performance of the running system as a whole, when a lot of FFI traffic is flowing across the WASI boundary. The richer component model enables lower impedance mismatches and "thinner" FFI-layer implementations.
For example, from the OP:
> WASI 0.2 handed you an output-stream that you wrote into imperatively. WASI 0.3 has you pass in a stream<u8> and get back a future that resolves when the write completes.
For some host languages/runtimes, "imperative blocking write calls" is already how writes against IO descriptors are exposed to the programmer. For those languages, WASI 0.2 made sense.
But in other host languages/runtimes, writes against IO descriptors are inherently non-blocking, returning promises or yielding. For those languages, WASI 0.2 "left performance on the table." WASI 0.2 required such languages to implement a blocking IO write abstraction on top of their non-blocking IO write semantics, in order to pass that blocking-IO-write primitive into the WebAssembly componennt... even if the WebAssembly component was internally concurrent (e.g. compiled from a language like Golang) and so would highly benefit from a non-blocking-IO-write primitive!
Meanwhile, if you require that the host expose a non-blocking-IO-write primitive (as WASI 0.3 does), then for hosts with native non-blocking IO, doing so is free; while for hosts with only blocking IO, non-blocking IO can be "faked" basically for free (i.e. with a global or per-resource linearized write queue on the host side.) And likewise, non-blocking-IO-aware WebAssembly components can freely take advantage of NIO; while blocking-IO-aware WebAssembly components only need the tiniest added bit of codegen shim (`blocking_write(x) => await nonblocking_write(x);`) to fit into a WASI 0.3 world.
In other words, implementing nonblocking IO abstractions on top of blocking IO abstractions costs FFI performance, but implementing blocking IO abstractions on top of nonblocking IO abstractions is "free" (in FFI terms.)
---
That being said...
The WASI devs were likely aware of the "FFI optimization opportunities being left on the floor" in WASI 0.2. They likely already wanted to take things in this direction from the beginning. But it was impossible, in WASI 0.2, to express the concept of a promise/future (or any of several of the other abstractions introduced in WASI 0.3 that the component-model changes depend on.) They needed to introduce this more "opinionated" (i.e. richer) component model in order to get here.
AFAICT, WASI 0.2 was never intended to be a Release Candidate of the WASI spec. (And WASI 0.3 likely isn't either!)
Rather, WASI 0.2 had areas (like IO) that were purposefully left "under-baked". The WASI team knew people needed some version of these primitives in order for WebAssembly components to usefully integrate into systems at all. But they hadn't yet put in the work on designing how certain aspects of WASI (e.g. async) would work. So they designed WASI 0.2 as a prototype design, based on the limited toolbag of primitives they had already fully agreed upon. Some aspects of WASI turned out to only "want" that limited toolbag of primitives, and so didn't change at all under WASI 0.3 (and might even be in their final shapes.) Other aspects "wanted" things that weren't there, and so experienced over-constrained designs under WASI 0.2, replaced with less-constrained designs under WASI 0.3.
I fully expect there will be more such changes under WASI 0.4.
Also to be fair "just copying" works really really well, especially for standards. The primary goal of standardization is not to invent something new, but to have a target that isn't constantly moving.
If you want to build something new and better do that, and if you are ready to build a standard based of it which is very valid. You can also build them together, and CloudABI which they mention as inspiration in their readme for example did it that way. All valid paths.
But you want to start out simple and something common so that people that make use of the standard have an easy time to implement it. After all having more than one implementation is why you need a standard. Otherwise it's maybe a specification, which again, fair enough.
I can stand behind not copying Unix until the end of time, but "Unix" is a common target that people know how to implement and use. And while not even the authors of Unix claim it's great or even good it is something that people already implement (often enough even when not targeting anything unixy at all) so if your goal is to create a standard that those people can target then abandoning that does seem like a wrong move.
Don't get me wrong: I think C is cute and fills a niche decently well. But that niche is not the one we have here.
The reasons why Unix displaced a bunch of more elegant systems were downward scalability, free distribution, and positioning to take advantage of network effects. Quality was secondary, especially with multiprocessing and networking where a lot had to change, and the designs were not always good.
Sometimes bad designs stick around due to pure inertia
For my "TagLib for TypeScript" library, I use WASI for local filesystem operations when used with Node.js/Deno/Bun. https://github.com/CharlesWiltgen/taglib-wasm
It's quite specific though as I'm working on support programming in the browser.
If you are not deep into letting a very specific kind of user extend, it's probably overkill.
Even then it's a very VERY niche thing because it has to be simultaneously :
- someone who is opinionated about a programming language (either because they know too much, i.e. expert, or not enough, i.e beginner)
- is dedicated enough to want to try to build something on top of an existing system
- does not want to bother with solutions you mentioned
It has to compete with more domain-adapted use cases though. Does WASM make more sense than eBPF for packet filtering? It doesn't seem to make more sense than JavaScript for making websites. Maybe it makes more sense for deploying edge services (which IIUC is the main use case for WASI).
Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development system.
The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy.
To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.
Is this really a representative use-case of WASM/WASI? Would'n it be much better to compile Dart to WASM (the Dart SDK even supports "dart compile wasm")?
Do you expect everyone to hand-code their websites in WASM? Do you expect every webapp be cross-compiled to WASM?
From where I'm standing, WASM is extremely successful in its specific niches: in enabling islands of high-performance in otherwise web-based software, and in sandboxing plugins to native apps/servers.
It's used heavily by major web apps like Figma, it's used to run non-Javascript languages on Cloudflare Workers, many compute-heavy web libraries rely on Wasm modules, many web games rely on Wasm, it's used for safe plugins in some native apps like Microsoft Flight Simulator, amongst other use cases.
It has little to do with the webassembly in the browser.
I use it to extend a native application, for example. No browser in sight at all.
The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits.
The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication)
Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.
https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
WebAssembly has been a great success thanks to its excellent initial design.
-"hey, look at our C Rust FORTRAN to WASM translator, blahblah"
-"uhm, cool, how do I debug it?"
-"yeah...about that...you cant!"
So wasm is a really strange compilation target for systems programming languages.
I mean there _are_ ways to debug it in a browser but they sort of suck.
That feels pretty revolutionary, no need to setup your local system to get core concepts.
Even have plans to use postgres in WASM (pglite), and I know a few real time apps use sqlite in WASM.