"WASI 0.2 Launched" (2024-01)
https://news.ycombinator.com/item?id=39289533 :
> At the same time, work towards WASI 0.3, also known as WASI Preview 3, will be getting underway. The major banner of WASI 0.3 is async, and adding the future and stream types to Wit. And here again, the theme is composability. It’s one thing to do async, it’s another to do composable async, where two components that are async can be composed together without either event loop having to be nested inside the other. Designing an async system flexible enough for Rust, C#, JavaScript, Go, and many others, which all have their own perspectives on async, will take some time, so while the design work is starting now, WASI 0.3 is expected to be at least a year away.
WebAssembly/WASI > WASI Preview 2:
https://github.com/WebAssembly/WASI/tree/main/wasip2
In WasmCloud makes strides with WASM component modelWebAssembly
WASI
Rust2019–2026
WebAssembly / WASI
WASI
WebAssembly System Interface
52Distinct people
57Mentions
0Explicit recommenders
5.8KGitHub stars
What to know before exploring
What it is
WebAssembly System Interface
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bytecodealliance/wasmtime · linked in 2 of the same discussions
- webassembly/component-model · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year57 dated mentions
Observed mentions: 2019-06-01 02:23:09 UTC to 2026-08-13 14:37:56 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 2 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
WebAssembly System Interface
The WebAssembly System Interface (WASI) is a set of APIs for WASI being
developed for eventual standardization by the WASI Subgroup, which is a
subgroup of the WebAssembly Community Group.
WASI started with launching what is now called Preview 1, an API using
the witx IDL, and it is now widely used. Its major influences are POSIX and
CloudABI.
WASI 0.2 (Preview 2) is a modular collection of APIs defined with the Wit IDL,
incorporating many of the lessons learned from WASI 0.1, including support for
a wider range of source languages, modularity, a more expressive type system,
and virtualizability.
WASI 0.3 (Preview 3) is the current preview. It builds on WASI 0.2, replacing
the earlier explicit streams and polling interfaces with the component model's
native, composable async functionality via the future and stream types.
Find the APIs
Development of each API happens in its own repo, which you can access
from the proposals list.
This repo is for general discussion, as well as documenting how we work
and high-level goals.
Propose a new API
If you would like to create a new proposal, get started with our
Contributing guide.
All new API proposals should use the new format and the new repo structure that is shown in the proposal template.
See the Wit in WASI document for more information about using Wit for WASI proposals.
Read the full README on GitHubWhat Hacker News says
7 sourcesEventually by using the component model which will expose the DOM API. It will get to direct wasm to WebIDL calls one day:
https://github.com/WebAssembly/component-model
The component model is being used for the WebAssembly System Interface (WASI). WASI provides operating system integration for wasm applications outside the browser:
https://github.com/WebAssembly/WASI/tree/main
In the meantime you can use JavaScript glue code auto-generated by your toolchain to access the DOM. This will be made better with builtins like the js-string-builtins proposal:
https://github.com/WebAssembly/js-string-builtins/blob/main/...
You can call JavaScript functions and DOM methods from wasm like this example from Hoot, which is a Scheme to wasm compiler:
https://spritely.institute/news/building-interactive-web-pag...
In Ask HN: What are some unpopular opinions you got?Very cool! I've been watching the "toolchains in Wasm" landscape for a while, and seeing a Clang/LLVM toolchain running in Wasm is awesome!
YoWASP has also had an LLVM toolchain working in Wasm for a while too[1], although it seems like this version solves the subprocess problem by providing an implementation of `posix_spawn` whereas the YoWASP one uses some patches to avoid subprocesses altogether
My biggest question marks around this version are about runtime/platform support. As I understand it, this toolchain uses WASIX, which (AFAICT) works with Wasmer's own runtime and with a browser shim, but with none of the other runtimes. Are there plans to get WASIX more widely adopted across more runtimes, or to get WASIX caught up to the latest WASI standard (preview2)? Or maybe even better, bring the missing features from WASIX to mainline W
Read the rest
ASI like `posix_spawn`[2]? I'd love to be able to adopt this toolchain, but it doesn't seem like WASIX support has really caught on across the other runtimes
[1]: https://discourse.llvm.org/t/rfc-building-llvm-for-webassemb...
[2]: https://github.com/WebAssembly/WASI/issues/414
WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in WASI.
At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contribut
Read the rest
ors so far.
By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .
Sadly, still no Framebuffer API for WASI GUI apps (https://github.com/WebAssembly/WASI/issues/174).
In WASI 0.2.0 and Why It Matters> As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity.
That's the underlying messy API it's built on. There are specs to make the API more standardized like https://github.com/WebAssembly/WASI
But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.
In Missing the Point of WebAssembly