Relationship to the component model?

[ajklein]

Linking together the module graphs of JS and Wasm is only part of what's required for fluid interoperation between JS and code compiled to Wasm (see, e.g., #53 for some open questions in this area). Regularly in Wasm CG discussions, the component model is cited as the overarching means by which cross-language interop should work. But I see no mention of it in this proposal (nor in the FAQ).

Is it plausible that in a component model world, the proper things to link together are not ES modules and Wasm modules, but ES modules and Wasm components? If that were the case, there might be risks in standardizing ESM modules before the component model is further along in its standardization.

I'm interested to hear the proposal champions' take, as well as @lukewagner & other component model folks.

[guybedford]

Thanks for calling this out, I've just posted a new readme update in #81 and added an FAQ section here exactly answering this question.

Please let me know if that answers your question or if you have further questions / feedback on this topic.

To your other point about usage - the ESM integration at this point offers the source phase import model as the primary means for obtaining Wasm modules in JavaScript and with the host instance linking model as secondary. This is because all Wasm use cases on the web can be supported via the source phase in a more tooling friendly way, while many Wasm modules likely won't work properly under host instance linking. That said, to speak to #53, you'd be surprised how many projects have figured out ways to make import("./file.wasm") work in the wild though under the ESM host instance linking model.

We do note in the readme that implementors may choose to ship the source phase implementation before the full instancing linking model as well if it presents a significant implementation cost. While the instancing model is not being pushed, it is still being enabled so that users and projects like Node.js and tools that have had this model behind a flag for a while can finally ship it but along with the source phase so that it is not constraining.

In terms of risks, I don't really see any myself here. Perhaps @lukewagner has some thoughts on this. If you have any specific concerns to raise now would be a good time to hear them!

[lukewagner]

Everything I've seen for how ESM-integration works with import and import source of core modules makes sense in a symmetric way for components, and all the examples I've seen make sense to me. I'd of course be worried that the devil is in the details, but I think @guybedford has implemented enough of component ESM-integration (via jco transpile) that I'm less worried here too.

Intuitively, the way I understand the interaction between component-linking and ESM-based-linking is:

• A component links a set of child components and core modules, ultimately forming a tree with 1 component as the root that entirely determines the interaction of the whole tree with the outside world (via the root's imports and exports).
• A pure wasm engine can load and execute this root component directly, supplying the root's imports and calling the root's exports, and the C-M semantics specifies exactly how all the root's child component/module instances are wired up as an encapsulated implementation detail of the root component.
• In a JS runtime, when you load a component via ESM, what you're loading is a root component and you're using ESM rules to determine the root's imports and make its exports visible to other ESMs, but how that root component is internally linked is still the exact same as in the pure wasm case (b/c it's defined by the C-M). But of course you can load multiple components via ESM, and so you end up with a forest of root components, each encapsulating a tree of wasm instances, and possibly linked to each other (via ESM).

So overall, I think the two models of linking compose in a 2-layer sort of way.

Another important goal is that it's possible to take a JS program that runs in a native JS engine and imports components with native ESM-integration and to compile that JS into a component (that runs on a pure wasm engine). I think that direction works too: imports turn into instance-typed imports and import sources turn into component-typed imports.

Another important case to consider is: components can import uninstantiated components and core modules (even from the root component); how does that work in ESM? And the simple answer is: uninstantiated component/core-module imports are interpreted via ESM as-if they were import sources.

Thus, there is a quite nice correspondence between import/import source in JS and instance-typed/component-typed imports in the Component Model.

I hope that helps, happy to discuss more.

[ajklein]

Thanks for the detailed responses! I'm going to have to chew on these for a bit to fully digest them, but it immediately helps me to see that you two are on the same page.

One followup to @guybedford's reply in the meantime:

That said, to speak to #53, you'd be surprised how many projects have figured out ways to make import("./file.wasm") work in the wild though under the ESM host instance linking model.

Would you be able to point at a few of these in-the-wild examples? That'd assist me as I try to catch up to your understanding of the space.

[guybedford]

Would you be able to point at a few of these in-the-wild examples? That'd assist me as I try to catch up to your understanding of the space.

Here is one - https://unpkg.com/browse/@automerge/[email protected]/bundler/automerge_wasm.js. Where the JS module wraps a Wasm module through the ESM integration with the JS -> Wasm dependence being fully ESM integration host-linkage compatible for a working library use case. I think the case of JS wrapping Wasm is most typical, but Wasm needing JS imports is of course needed as well, so its the ESM integration "sandwich". I could find another if you like as well but would need to do some digging as I can't recall offhand.

[ajklein]

Thanks for the additional FAQ entry, I think that's useful to have as documentation of the plan-of-record (including the link to the C-M docs).

It's also useful to understand that @guybedford sees source phase as the dominant case (and not just as a plausible first step). As I've been working through examples today, it does seem like the limitations due to cycles will likely make it hard for Emscripten (at least) to leverage host instance linking. But the example linked above does at least show that in some cases it's usable, and given that it's both usable and implemented I get the motivation to solidify the specification underlying those implementations.