Hacker News Reader

Comment by mc_woods | Hacker News Reader

The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get existing wasi binaries to run preview2, and of course, preview2 binaries won't work on non-preview 2 runtimes...

View on HN

For folks looking to learn more, the Component Model documentation is pretty good! I like this excerpt for explaining the core vs component split:

> components interact only through the Canonical ABI. Specifically, unlike core modules, components may not export Wasm memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, allowing a component that relies on Wasm GC (garbage collected) memory to collaborate with one that uses conventional linear memory.

Link: https://component-model.bytecodealliance.org/design/why-comp...

Hopefully it's trivial to push C structs around by value if poking around in other instances memory isn't allowed. Otherwise it sounds like a lot of hassle just to appease "fringe languages" ( ;P ) that don't have a linear memory model. This sort of "directly reading and writing the WASM heap" is quite essential for JS code that sits between a WASM instance and a web API for instance (in the "WASM in browsers" scenario).

...for instance how do you share large amounts of data between components then, there must be some sort of cheap way to safely share portions of memory between components right? Because there are situations where multiple copy steps are simply out of question.

If you watch the video I linked to in the sibling comment, Luke addresses that exact question around 21 minutes in. The WIT spec I also linked to talks about resources and handles in some depth.

I thought this keynote presentation[0] by Luke Wagner at Wasmcon was great and covered it very well. I also found the WIT Format design doc[1] in the component model repo to be the most complete explanation of how it's all going to hang together.

[0]: https://www.youtube.com/watch?v=tAACYA1Mwv4 [1]: https://github.com/WebAssembly/component-model/blob/main/des...

Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use).

When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practice.

There is WASIX as a "POSIX for WASM"

I'd encourage you to read up on the component model. The talk by Luke Wagner linked in other comments is incredibly informative if you can make time to watch it. It's not about replacing WASI, it's about providing a coherent model for both implementing APIs like WASI and also providing structure and tooling for integrating codebases together in a sensible way using WebAssembly.

Reply on news.ycombinator.com