- Where: zoom.us
- When: February 27th, 5pm-6pm UTC (February 13th, 9am-10am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Proposals and discussions
- Update and phase 3 poll for ESM Integration (Guy Bedford, 25 minutes)
- Closure
None
None
- Thomas Lively
- Keith Winstein
- Sergey Rubanov
- Deepti Gandluri
- Conrad Watt
- Zalim Bashorov
- Nick Fitzgerald
- Alon Zakai
- Dan Phillips
- Daniel Hillerström
- Robin Freyler
- Ilya Rezvov
- Fedor Smirnov
- Paolo Severini
- Alex Crichton
- Paul
- Yury Delendik
- Michael Ficarra
- Guy Bedford
- Luke Wagner
- Heejin Ahn
- Emanuel Ziegler
- Richard Winterton
- Ryan Hunt
- Jeff Charles
- Dan Gohman
- Patrick Hickey
- Johnnie Birch
- Jakob Kummerow
- Ashley Nelson
- Brendan Dahl
- Sam Clegg
- Derek Schuff
- abrown
- Paul
- Slava Kuzmich
- Nuno Perreira
- Dean Srebnik
Guy Bedford presenting slides
CW: question: does this also generalization give us a path for representing compile-time imports in the ecosystem?
GB: I think the ESM integration in general has some interesting interaction with compile time imports. What the source phase does is it distinguishes between the full expressivity of the instantiation where you want to directly pass the imports and the esm integration. Esm integration is the just works pass. The source phase is more like binaries for today, where we need to provide a bunch of layering in-between. The compile-time imports defaults are potentially interesting in both cases, and maybe slightly orthogonal.
CW: If there was something on the top of your head that represents incompatibility but in the absence of that it seems like things are okay.
GB: right: as far as I've thought about compile-time imports recently, I don’t know of any incompatibility
GB: [presenting import phase syntax]
DG: Deferred evaluation question. What stage is that proposal at in TC39 and do you have more signals about the interest levels for stage advancements?
GB: Need to double check, unless someone knows off the top of their head? I think it’s stage 2 - “Deferring Module Evaluation”
DG: Think it’s stage 2 but was interested in the second part of the question, feedback or interest from TC39 about stage advancement
GB: Bloomberg was most interested in this and were working with Igalia on it, there was considerable investment for their use case, since they use this technique in their internal systems and wanted there to be a standard way. I haven’t heard any negative sentiment about it explicitly. Not sure how close it is to progressing but it’s an active proposal.
GB: [presenting ESM phase imports]
IR: Is it going to be polyfillable without ESM modules? Could you construct a JS representation without ESM?
GB: There are different levels of toolchain support. Can imagine a build tool turning this into doing the right thing doing the syntax today. You’d write this but it would be writing JS that is supported in current browsers to do the same thing. We have the same for Source Phase imports in esm integration, where tools can rewrite it to something that works today. Can immediately get benefits. In terms of a browser polyfill, some approaches, will discuss in the implementation slide.
GB: [presenting module loading phases]
DG: a couple of questions: the documentation in the current module repository: haven’t looked recently, does it pull from the TC39 proposals that are not yet at stage 3? How should we think about the dependencies between TC39 and the CG? The 2nd note for the group: WPT are a great set of tests, but we also usually recommend at least some API tests in the wasm test repository (just in terms of process). I could go both ways on that, in Chrome we can run WPT right out of the box but I’m curious how others think of WPT as meeting the testing requirement.
GB: On the first point, can you clarify what you mean by state of the documentation?
DG: The proposal overview of the spec, the text assume dependencies on stage 1 or stage 2 TC39 proposals.
GB: it’s kind of a chicken-and-egg thing. We’ve gone I think as far as we can without some further signal from the wasm CG. source phase is at stage 3, which in the JS process is very advanced, basically it’s done and ready for implementation in browsers. Traditionally we had problems in stage 3 in TC39 because things advance there and get implemented and it’s too hard to change. TC39 recently introduced phase 2.7 to try to fix that but source phase is at stage 3. We’d need browser implementations to get to phase 4 but that means more progress on the wasm side first. The synchronous instantiation/deferred evaluation isn’t a dependency, it’s more about compatibility.
DG: yeah. I’d still be curious to hear from the group about testing, and interest from runtimes for implementation.
CW: For the other proposals, we had engines implementations at Phase 2/Phase 1, that’s perhaps a signal that we would be interested in anyway.
GB: Signals were the implementation was ready to go and so we had it moving forward. Deno had an implementation moving forward. They were ready to go live back in 2022 and we held back because we wanted to flesh out the source phase. Did not want to release a feature that provided part of the functionality, and result in a cliff for user support. Potentially an ecosystem effect that would kind of divide or distort the ecosystem. With source phase, we now need to send a signal that this is ready. This is the process we’re in now. We need to reverse that signal. We need to work with the CG to build trust from browsers.
CW: Do I understand correctly that just form TC39 point of view, the blocker is just that they need more web implementations?
GC: There’s no blocker at TC39, there just needs to be a positive signal from the Wasm CG. The TC39 stage 4 we can have when we have web implementations, its more about building implementation trust.
DG: In terms of signal, GB corect me if you’re wrong. You’re just lookjing for a signal from the CG. Procedurally, most of the requirements of Phase 3 have been met, except for the testing question. If looking for a general, positive signal, maybe if interested members can speak to that, now is the time to do so.
RH: I may have missed this previously: does this run against any implementation? I guess the spec interpreter is not a web engine, is that the issue with the testing?
GB: Right, requires the full HTML integration, the full details come through the full HTML integration side. Yes. Getting end to end testing is either in JS tooling or having full support in engine like JS or another browser. In general we have that with the webkit implementation but it doesn’t have source phase yet.
RH: In terms of JS tooling, do any of them have requirements from the proposal?
GB: Right. The domain areas are, for TC39, its syntax and builtin behaviors. For wasm it’s graph execution behaviors and HTML integration behaviors. In Babel we have an implementation of parsing, loading behaviors for source phase and conversion to ES modules. The HTML integration in theory is testable though the polyfill of ES module shims. Im working on that currently. I should be able to release a version of that with support for all the specs very soon. Other than that I guess deno did also have esm integration previously without source phase, maybe node too. But they’ll need browser support for the syntax to move forward with source phase. Traditionally the signal has been “esm integration isn't moving forward, there are issues”. The key thing to say is it is moving forward, and it is ready to go - however we say that its ready to go is less important
RH: Sounds like there are some implementations of earlier versions of this, but they’re not fully complete, parts missing. Not the case that there is absolutely no testing. Historically, don’t know how complete testing is required for other features.
GB: Yes. The WPT tests that Safari did were quite comprehensive. They were close to unflagging that implementation. The only source phase implementation we have right now is through Babel. As a tooling user I can get the benefits of that syntax already through the plugin. It’s not going to patch webassembly.module but users can get most of the benefits today.
RH: On the question of browser interest, where Mozilla is coming from is that it wasn’t ready to implement, the second reason is resources, no big concerns about the proposal itself, we would just have the resources to implement it
GB: Yeah on paper it seems like we mostly have the requirements for phase 3, short of the fact that it’s not a self-contained test suite, which i guess it he main technicality. It seems like we have most of the pieces in spirit, maybe folks need time to digest it. We don’t need to get phase 3 today but I want to start working toward getting that signal of intent and getting people aware that this is ready for implementation and the concerns have been worked through. Phase 3 would be a strong way to send that.
CW: Can I ask a pointed question about Chrome, what’s their general interest in this?
DG: In a similar position to Firefox. Generally interested, don’t have any immediate plans to implement it, but no objections. Positive signal.
CW: So i would be comfortable going to phase 3 on the basis of a polyfill. It sounds like maybe the polyfill is a little incomplete? It sounds like it’s missing source phase imports?
GB: You’re making more work for me, but happy to take that requirement! That would be a nice validation point as well, looked into how much work it would be, and should be something we can cover in the ESM project, from syntax all the way to HTML integration. The difficulty again is, because of the HTML integration, treating it as a single test suite may be difficult. If it were to have a polyfill implementation, how would you want to define the tests for it. Should it run against the WPT tests?
CW: I'm personally comfortable with a polyfill that is reasonably complete and hits all the big features. Doesn’t have to hit all the edge cases. But source phase is a pretty big feature so there probably should be non-zero tests covering that.
DG: Speaking up in favor of CW’s interepretaion, reasonable set of some coverage, doesn’t have to be complete in terms of the polyfill, seems like a good requirement.
GB: In terms of where the testsuite lives, if it is just the WPT tests - is that acceptable?
CW: Totally fine, inviting people to disagree with me. If we are unhappy with the tests where they live, it’s on us to come up with something new, the current framework doesn’t support these types of tests.
GB: Web platform tests are the easiest path to remain on for polyfill testing. That would be a helpful clarification if we’re going to get the polyfill passing those tests.
CW: i would consider that fine. We’re just going to be working on consensus here i think so, unless someone objects i think that would be ok
DG: Sounds reasonable, in terms of next steps, there is a lot of information to digest in this presentation. How do folks feel about deferring the poll to phase 3? I do think there is enough positive signal from the group, at least that’s my interpretation. Maybe we don’t need a strict poll to phase 3. What do you think GB?
GB: I don’t think there’s a huge rush, let’s come back to the poll in a little while, and give people to reconsider the proposals and build up the context again. I’m happy to finish the polyfill and come back when it’s ready. It’s good to make sure we get it right. The important thing today is to say we have positive intent.
DS [chat]: Not with my "Chrome" hat on, but I'm also happy with the level of thought that's gone into this now, and it's looking pretty good to me. I know it's hard with all the dependencies, but I'm happy that we are making progress with this again.
ZB: [chat] JFTR we in Kotlin/Wasm are interested in the proposal, and we are trying to generate glue/service js code with the proposal in mind.
CW: For the benefit of the notes, we’ll believe the Phase 3 requirement will be fulfilled by the WPT tests, with a polyfill that allows them to run somewhere, including tests for source phase imports.
GB: that should be possible. If it turns out that there are issue with that, i’ll bring it back up but it seems sensible.
DG: thanks for the presentation