Tracking of DOM / WebIDL integration

[pannous]

What are the best places for tracking progress of DOM / WebIDL integration?

[tlively]

I'm not aware of any ongoing efforts specifically for DOM / WebIDL integration, but Emscripten has a WebIDL binder and the stringref proposal may help some languages call Web APIs faster and with less glue code. You also may be interested in the component model proposal, which provides much higher-level primitives for linking Wasm modules to each other and their environment.

[misyntropy]

Now that its been 1.5 years and GC has been implemented and made available in browsers, I would like to renew the question once more and ask: What next on the road to making Web API (DOM mainly) available within WASM? And pardon me for my relative ignorance in these matters, what is the relevance of the component model to the Web API?

[tlively]

As always, you can call Web APIs by importing them into Wasm modules with some JS glue. If toolchain providers provide that glue, then developers don't need to do anything further. The stringref proposal is no longer active, but the JS string builtins proposal provides access to imported string APIs without glue code, and we may follow a similar pattern with other JS primitives or higher level APIs if there is sufficient demand and potential performance benefit.

There are currently no plans to implement the component model natively in Web engines, but it can be polyfilled via jco and potentially other tools. If you provide a component model interface for Web APIs, then the ecosystem of component model tools will be able to generate binding code for that interface and let you link components with an implementation of that interface without additional per-toolchain or per-application work.

[misyntropy]

Thanks for the info, its kinda hard to follow what's happening.

1. Do you mean the component model will be built natively into WASI and the like, but not for web?
2. If the component model interface is implemented for web APIs, does it mean that there is no need of JS glue? I draw a distinction between a JS-glue and WIT-glue.
3. I am unable to comprehend the motivation for the JS-string proposal, I thought reference types were already completed and that all "external" types were being handled in a uniform manner. I also do not understand the idea of specially dealing with each and every native JS type.

[tlively]

1. Do you mean the component model will be built natively into WASI and the like, but not for web?

WASI is now defined in terms of the component model ad non-Web engines may natively implement the component model so they can consume Wasm components directly. In contrast, the Web will consume components via polyfill for the time being.

2. If the component model interface is implemented for web APIs, does it mean that there is no need of JS glue? I draw a distinction between a JS-glue and WIT-glue.

The tools generating the component model polyfill would generate the necessary JS-glue, but since that glue code implements WIT definitions, you could also consider it WIT glue.

3. I am unable to comprehend the motivation for the JS-string proposal, I thought reference types were already completed and that all "external" types were being handled in a uniform manner. I also do not understand the idea of specially dealing with each and every native JS type.

For something as frequently accessed as strings, there is high cost to calling out to JS for every operation, e.g. extracting a single character. That proposal lets Web engines inline all the string operations to improve performance. At the core Wasm level, this is still just representing strings with externrefs and calling imports to manipulate them, just like with any other external data.