cargo-wasi VS WASI

There are many options, but what worked best for me is compiling with cargo-wasi and loading the resulting Wasm file with browser_wasi_shim. Using wasm32-wasi instead of wasm32-unknown-unknown requires a bit more work (the communication with JS has to be set up manually), but gives the flexibility of having just a Wasm file that can be dropped in and loaded dynamically. (There's wit-bindgen for generating wrapping code according to an interface definition but I didn't have much success with it.)

I use cargo-wasi to build it:

Wasm is getting merged in and designed in a way that it is "drop in". As in, the standard libs are written to do WASI calls instead of libc (or whatever else) for standard I/O concerns.

This is represented in some languages better than others -- for many languages you just switch the "target" -- from x86_64-unknown-linux-gnu to wasm32-wasip2 (ex. Rust). Some things won't work, but most/many will (simple file access, etc), as they are covered under WASI[0]

That's not to say that nothing will change, because there are some technologies that cannot be simply ported, but the explicit goal is to not require porting.

[0]: https://github.com/WebAssembly/WASI/tree/main/wasip2

Eventually 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):

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...

And a special thank you to everyone who has been contributing and continues contribute to the WebAssembly ecosystem particularly to the maintainers of the Bytecode Alliance projects, the Wasmtime project and the developers working on WASI and the WebAssembly component model. Their work is instrumental in supporting Spin.

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 contributors 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... .

> 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.

Snapshot Preview 1 is the standard all tools are building to right now. The specification is available here: https://github.com/WebAssembly/WASI/blob/main/legacy/preview...

It's pretty unreadable though!

Preview 2 looks like it will be a big change, and is just being finalised at the moment. I'd expect that when preview 2 is available there will be an improvement in the quality of documentation. I'm not sure how long it will take after release for tools to start switching to it. I'd expect Preview 1 will still be the main target at least for the rest of this year.