Timeline for the Component Model and async questions

[tareksander]

Is there a timeline for when the Component Model will reach stability, and for when browsers will start supporting it?
And would it be possible to polyfill the async support with the existing JS Promise integration, in case WASM runtimes are faster to implement it that browser engines?
Will the async model allow for pausing execution inside a component, e.g. to return control back to the browser event loop without having to return out of the component?

[lukewagner]

With WASI Preview 2 we already have a pretty good island of stability in that, even as we progress to Preview 3 and 1.0 after that, we'll keep Preview 2 components working (either by supporting both simultaneously or creating tools (analogous to the preview1 component adapter used by wit-component) that can automatically convert a Preview 2 component into a Preview 3 or 1.0 component.

That being said, we have a ways to go before reaching a stable standard "WASI 1.0" (entailing a Component Model 1.0). @pchickey had a good presentation at the last WASI meeting about the plan to work toward WASI 0.3 over the next year in parallel with incrementally improving WASI 0.2 via minor 0.2.* releases. Once we hit 0.3, then we can consider the final additions to make a complete MVP "1.0" release.

In the meantime, we're not really blocking on native browser support because we have a fantastic polyfill in jco transpile that, iiuc, is being incrementally integrated with JS bundlers so that you can use components as ESMs (importing them via import, etc). Also, browsers have their plates full this year, implementation-wise, polishing off wasm-gc and shifting their focus to shared-everything-threads and stack-switching, all of which is much harder to polyfill and thus appropriately (IMO) a higher priority than natively implementing the Component Model.

And would it be possible to polyfill the async support with the existing JS Promise integration

Yes, it's definitely a goal for jco transpile to be able to use JSPI to polyfill Preview 3 async.

Will the async model allow for pausing execution inside a component, e.g. to return control back to the browser event loop without having to return out of the component?

Yep! Today, we'd polyfill it via Binaryen's asyncify, which has non-trivial runtime and size overhead and with native JSPI in browsers, we'd be able to avoid that overhead.

If you want to see more the sketch of async, see these slides presented recently. I'll also try to give a somewhat shorter and higher-level overview next week at Wasm I/O.

[tareksander]

Thanks for the many great resources! So the Component Model is a subproject of WASI and tied to its versioning, at least up to 1.0.

In the meantime, we're not really blocking on native browser support because we have a fantastic polyfill in jco transpile

IIUC that transpiles the whole component into JS, instead of transpiling into a core WASM module and a JS shim for the component model interaction. Isn't that giving up some of the benefits of WebAssembly?

Also, is the WASI shim in jco supposed to be the standard WASI shim for the web going forward, or is it expected that many developers will need to use a third-party more complete shim?

What will the migration path be from wasm:io pollable to the async Component Model types? How should I design an async WASI API today for future compatibility?

[lukewagner]

Thanks for the many great resources! So the Component Model is a subproject of WASI and tied to its versioning, at least up to 1.0.

For now, yes, to minimize the number of moving pieces and possible version mismatches, we're lumping the C-M and WASI together under one monolithic version. In terms of their eventual specifications, the Component Model would get its own spec and has already been included as a future deliverable in the official WebAssembly WG Charter. WASI has farther to go to get scoped and chartered, but it would be one or multiple separate specification documents.

IIUC that transpiles the whole component into JS, instead of transpiling into a core WASM module and a JS shim for the component model interaction.

I don't believe so (at least, not in default builds); I think it does in fact produce one or more core .wasms (extracted without modification from the component) and .js glue wrappers.

What will the migration path be from wasm:io pollable to the async Component Model types? How should I design an async WASI API today for future compatibility?

With Preview 3, the goal is for wasi:io to disappear completely. To see a sketch of this, check out the wasi:http@0.3.0-draft being worked on here and experimentally polyfilled here. The tl;dr is that all the uses of wasi:io/poll.{pollable} are replaced with C-M built-in stream<T> and future<T> type constructors (noting that, because all functions can be lowered async, functions don't need to explicitly use future<T>, they can just return T and an async caller effectively getting a future<T>. And then the C-M adds a built-in way to wait for an event to occur on a future/stream (replacing wasi:io/poll.poll).

[tareksander]

IIUC that transpiles the whole component into JS, instead of transpiling into a core WASM module and a JS shim for the component model interaction.

I don't believe so (at least, not in default builds); I think it does in fact produce one or more core .wasms (extracted without modification from the component) and .js glue wrappers.

Ok, the calling of wasm2js made me think otherwise.

Will C/C++ component support be included in the WASI SDK? Or will there be a separate project for that? Is there a way to use C/C++ components today?

[lukewagner]

There is low-level (rather verbose, mostly meant to be used to build other things) C bindings in wit-bindgen now, and iiuc, recent work here to add higher-level, safer bindings using C++.

[tareksander]

Great, I haven't found the C support since it's not listed in the Component Model docs, maybe worth listing C even if it's low-level and verbose, (as frankly most C APIs are anyways, so it shouldn't take much getting used to if you know C), and I also found TinyGo in the Readme. I wanted to add Lua as a language for the Component Model, which requires C with Component Model support. I think that were all questions I have for now, Thanks again.