I'm still trying to get my head around the differences between WASI Preview 2 which was announced in January I believe, and what the WebAssembly Component Model represents.
Is it fair to say the Wasm Component Model is still being evolved, but a significant snapshot was made at the time to support the WASI 0.2 release?
If I want to approach a project that is a framework that uses Wasm modules, Wasm core modules, in their client side (browser side) deployment, and I want to ask about incorporating the idea of component modules (component modules could be composed before being delivered as a core module to a browser, and component modules could be used on the server side with the inclusion of a library like WasmTime
),
what's the right way to frame what has been made possible this year? To be accurate, does one say "WASI Preview 2", WASI 0.2, was released, or does one say something like a Minimal Viable Product for Wasm Component Models has been released?
It's my impression WASI comes with connotations of bridging a Wasm guest with an operating system, usually not with a DOM. I know WASI glue code is often used to allow a Wasm guest with some WASI calls to run in a browser. But when the exciting new feature is that the component model allows reuse of Wasm binaries in different environments, and in combination with each other, due to the more efficient composition that is now possible, it feels odd to be pointing out the WASI 0.2 was released.
Is the name WASI being repurposed to be less about bridging OS capabilities and now it represents a new way to wrap some Wasm modules so they carry their own ABI in a standardized way?
Or is there a simpler way to view what early this year represents?
We do often conflate WASI and the Component Model because WASI 0.2 has represented the primary motivating use case for implementation of the Component Model. I would say that a certain set of Component Model features have been released alongside (in support of) WASI 0.2 which can be expected to be as stable as WASI 0.2 itself.
In practice I would expect this to continue in the medium term, with Component Model features being added primarily to support new WASI features, though you are correct that the CM is independent of - and can be used without - WASI.
Another way to think about WASI is that it's just a standardized set of wit worlds. There's no difference between WASI and any wit definitions that you might write with the one exception that WASI is standardized under the name WASI.
WASI, taken this way, is the type system defined by WIT that map to canonical abi calls, and that's it. Yes?
Last updated: Nov 22 2024 at 17:03 UTC