The Road to the WASM Component Model 1.0

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access.

I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cross-platform sandboxing solution for running real applications.

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

I will be interested in getting details about the experiments of Ryan Hunt about DOM performances.

I am currently developing a WASI runtime for exaequOS and Woua programming language that will target WASI and will have access to DOM through a virtual/dev/dom driver.

wex —dir /dev /usr/tests/woua/dom_demo.wasm

I’m curious if this helps make WASM a potential alternative to eBPF for userspace kernel extensions.

The microkernel analogy for the Component Model vs WASI is actually a really useful mental model that I hadn't seen framed that way before. Component Model as the always-present kernel, WASI as optional OS services on top. That framing makes it obvious why browser implementation of the Component Model is tractable even though browsers have strong opinions about I/O, and why 1.0 for the Component Model and WASI are separate milestones. The lazy ABI change is also underrated, zero-copy forwarding between calls is going to matter a lot for the use cases where WASM actually competes with native.

So, Jini with RMI, CORBA, DCOM, and gRPC, hello again.

Really leave WASM on the browser.

Oh yes give me the component model lets go.

Very exited about WASM/WCM as a portable format for capability-secure applications.

I had a spec file sitting around for an OS project idea I had, where the kernel would just be the WASM compiler + a few small shim drivers, and everything else (including e.g. PCIe device drivers) would be WASM modules with WIT interface specs. I handed the spec off to Fable and it seems to have made a working proof-of-concept. Has a maximally-WASM OS running on browser/QEMU/Orange Pi. https://eo9.org

> The Component Model can’t formally reach 1.0 without native implementation in at least two browser engines.

I don't quite understand why the Component Model is now suddenly a browser thing, and on top something that needs to be implemented natively in browsers instead of a convention between different compiler toolchains.

Keep that boondoggle in WASI and the Bytecode Alliance. WASM in the browser works just fine without the added runtime complexity.

WASM first appeared in 2017.

It still hasn't really reached a breakthrough.

Billions use HTML+CSS+JavaScript. Who really uses WASM? There are of course users, but very, very few in absolute numbers. Many projects are not web-based really. For Autodesk Fusion, as one example for many, I have some mega-slow application that takes forever to work with in some cases on my laptop (it is not the fastest laptop, but I recently tested this on a faster desktop computer with 32GB RAM and it is still slow to no ends; using it all WASM based would be even slower I bet. That's not winning anyone over ...).

Please please please bring it to the browser. I'm so done with the terrible ergonomics of everything at the was bounary having to pretend it's JavaScript