CG-12-03.md

Agenda for the December 3rd video call of WebAssembly's Community Group

• Where: Virtual meeting
• When: 2024-12-03, 17:00-18:00 UTC (2024-12-03, 9am-10am PST, 18:00-19:00 CET)
• Location: link on W3C calendar or Google Calendar invitation

Registration

No registration is required for VC meetings. The meeting is open to CG members only.

Agenda items

1. Opening
2. Proposals and discussions
   1. meetings/#1683 closed, next in-person meeting is Feb 11-13 hosted by Fastly in San Francisco. Please fill out this form if you plan to attend in person. (Luke Wagner, 2 minutes)
   2. Update on the new ESM Integration semantics from the ESM Phase Imports proposal (Guy Bedford, 25 minutes)
3. Closure

Agenda items for future meetings

None

Meeting Notes

Attendees

• Thomas Lively
• Derek Schuff
• Hunter Demeyer
• Paolo Severini
• Jeff Charles
• Paul Dennis
• Elizabeth Gilbert
• Manos Koukoutos
• Chris Fallin
• Ilya Rezvov
• Oscar Spencer
• Yury Delendik
• Francis McCabe
• Ben Titzer
• Brendan Dahl
• Johnnie Birch
• Matthias Blume
• Julien Pages
• Daniel Lehmann
• Andrew Brown
• Adam Klien
• Emanuel Ziegler
• Ben Visness
• Ricky Vetter
• Zalim Bashorov
• Sven Sauleau
• Jakob Kummerow
• Chris Woods
• Luke Wagner
• Dan Gohman
• Richard Winterton
• Guy Bedford
• Kevin Moore
• Nick Fitzgerald
• Heejin Ahn
• Linwei Shang

Proposals and discussions

1. meetings/#1683 closed, next in-person meeting is Feb 11-13 hosted by Fastly in San Francisco.

Please fill out this form if you plan to attend in person. You will also be able to join remotely.

Tuesday, February 11 will be a WebAssembly Research Day and the CG meeting will follow on the 12th and 13th.

2. Update on the new ESM Integration semantics from the ESM Phase Imports proposal

GB: Will be giving this presentation at TC39 to bring ESM phase imports to stage 2.7. Want to update the CG as well. It builds on source phase imports.

GB presenting slides

AK: Can you say more about what you’re defining for Wasm here? Most of this looks like it defines JS and takes things defined in wasm and defines them for JS.

GB: The ECMA262 machinery we're defining here will naturally apply to Wasm. When we add support for dynamically importing a module in its source phase, that will also apply to Wasm modules because they are source-phase objects. We would be supporting dynamic import of WebAssembly.Module.

AK: Do you have a slide for what it means to import a source object?

GB: this comes from the module expressions proposal, it’s a new type of dynamic import for a module expression, represented by its module source object in JS; WA.Module has been defined as a module source in the source phase proposal.

AK: So you import a source thing, and you get back an instance?

GB: Yes. You get the canonical instance.

AK: So it's a new meaning for dynamic import, a new way of using it that’s more like instantiate.

GB: yes, registry-coalescing instantiation. Also the other new thing is this worker creation thing, creating it from a module instead of a URL

TL: You mentioned a canonical instance. That’s new, we don't have that now. So if you use the new dynamic import machinery several times, you get the same instance back, including mutated state. Across different contexts/ workers, you get different instances. If this new mechanism does instantiation underneath, how do you supply imports?

GB this is an update to the ESM integration semantics. We’d update that to support the new hooks that this provides, it's like source phase v2. This proposal does deprecate one of the hooks from the source phase proposal and replace it with a new hook; getting a module record from the instance. The ESM integration is in phase 3, so there’s some process questions about how we’d change that while in phase 3.

TL: you’re saying that the mechanism for providing imports is already specified in the phase 3 ESM proposal?

GB: as soon as we get to stage 2.7 I’ll update the wasm ESM integration proposal. I can bring the changes back here, or just give an update once we change it.

TL: I’m not too concerned about the process, more about what the proposal will look like, just wondering how providing the imports will work.

GB: dynamic import doesn’t support passing in custom import resolutions, similar to JS. in JS we’ll first focus spec work on [], they are more like inline modules. We do want to get to custom instantiations in JS, provide hooks into the resolution system, and have a registry identity with the canonical instances. It’s a long-term thing for JS but TC39 wants to get there eventually.

LW: there are also import maps to provide some of that

TL: So if I want to provide a bunch of JS functions to import to a Wasm instance, I create a JS module that exports those?

GB: yes, also for workers, we want to add to HTML standard to set the import map on a worker

AK: this isn’t really about what you have today, but the question about phase 3 changes. For Chrome at least, our current plan is to do the minimal source phase thing (where the spec allows minimal behavior). I”m not aware of other browser engines that will go further. As we keep adding more to the ESM integration, i’m wondering if it makes sense to split the minimal thing into its own piece that can advance while we have more modifications.

GB: the spec text is relatively simple (showing the diff), and we don’t foresee more changes to the ESM integration after that. I think what we’ll see node.js and deno are very interested in the instance level support and even shipping soon. That server interest may drive browser interest too. So it seems like an implementation convenience as opposed to an endpoint.

AK: To be clear, my concern is not about the specification text, but about what users can expect semantically. It's useful to know about the server-side interest.

GB: any further feedback. Let me know, it’s a good time to get it right now.

TL: thanks, that’s our agenda. Don’t forget to register for the in-person meeting in February if you want to attend.

Closure