Thanks for sharing. I’m eager to look at the current state of affairs of WebAssembly. If I remember correctly, the most interesting part would be WASI, the system interface. Particularly the networking and filesystem APIs that need to be capability-based.
For now, WASM is mostly suited for libraries that do not interact with system APIs, say a mathematical or cryptographic library that just relies on executing primitive instructions. If WASI is implemented correctly, then it would provide the system interface and even crates like
safe_network could be run in this environment. But, that gives food for thought: browsers are sandboxes and if they execute WASM/WASI, then they probably will not allow instantiating a TCP/UDP connection. Unless capability-based implementations make it such that the browser asks the user if the website may open a such a connection.
What I saw popup in the ecosystem were ‘runners’ that run WASM providing these system interfaces that WASI currently is formally lacking.
Yes, WASI is very promising. I used it for the p2p git portal talking first with Go and then with Rust. The Rust WASI target isn’t maintained though so I think it will break or be broken already. I started a conversation with Fermyon around this as they are using Rust for their CMS, but maybe not in the browser.
They are using HTTP via WAGI but maybe that’s server side rather than Browser, not least because WASI doesn’t support the network interfaces yet (well last I looked over a year ago). That said, Fermyon might have done some work on that with their experimental libs - I’ve not checked but would be interested to hear back if you look into what they’re doing in the browser.