Meeting minutes
<andreubotella> https://
<andreubotella> https://
Andreu: WinterTC is the ECMA Web-interoperable Runtimes Technical Committee
[Discussion on recording the breakout]
[Recording approved]
<florian> [Process rules about recordings: https://
Andreu: We'll be going through what each of these things mean.
… JavaScript runtimes are environments that run JavaScript and provide a way for it to do inputs/outputs.
… Browsers are JS runtimes in practice.
… They give you DOM as output.
Andreu: Server-side.
… Node.js, Deno and so on are very general-purpose OS processes.
… They're often used as servers in practice. E.g., node.js gave you a huge advantage over traditional servers when it first came out as a way to handle concurrent requests more efficiently.
… Other runtimes are edge runtimes such Cloudflare workers. Only meant as server usage. Deno deploy is another example. You also see this with various Node.js based solutions.
Andreu: Now Web interoperability.
… Why care?
… More code reuse is a good thing. Being able to run the same code on the client and on the server.
… If there's alignment, there's less need for polyfills, e.g. node-fetch, isomorphic-fetch that are no longer needed in Node.js now that it supports fetch directly.
… But also same documentation (e.g., on MDN).
… In general, it reduces lock-in.
… The web platform is the largets dev platform in the world, it makes sense to use it.
… Many server-side runtimes are web-interoperable but in some cases, there are differences due to the nature of the runtime.
… One example is how relative URL are resolved in fetch in such runtimes.
… The runtime may simply throw, because there's no good base URL.
… In some other cases, the server runtime may extent the specs in subtle ways because they have different requirements.
… This creates potential compatibility issues.
… Some common needs are different compared to browsers, e.g., HTTP server API.
… or networking protocols that cannot be exposed to web runtimes.
… We need a venue to extend the base functionality in web specifications.
… In May 2022, some engineers started the WinterCG. We did it to allow open collaboration without membership requirements.
… As we could not publish technical specs, we considered moving to a standardization venue.
… We considered a W3C WG or an ECMA TC.
… We had good discussions with both.
… A number of the members of the WinterTC were not members of W3C but were members of ECMA.
… In the end, we decided to shut down the Winter CG and create a TC at ECMA.
… This is how ECma TC55 was formed.
… Moving things once from a CG to ECMA worked fine, but cannot be done on an ongoing basis.
Andreu: What are we working on?
… A minimum common web API, a WinterTC test suite, and then a Sockets API and a CLI API to have access to env variables, files/directories, and so on.
… We are also contributing to upstream specs, typically Fetch (to remove cross-origin restrictions that do not apply to server runtimes) and the WebCrypto API.
Andreu: For the Minimum common web API, we're shooting as a superset of [Exposed=*] APIs. Goal is to publish yearly snapshots.
… In the future, we're planning to have conformance levels, e.g., to have levels such as Graphics, CLI/File Systems, and also possibly Servers with advanced networking APIs.
Andreu: I've hinted on differences for Fetch.
… There is no current page, no cookie jar, no referrer, while the spec assumes these exist.
… There's also no need to protect against cross-site requests.
… Goal is to standardize these differences. The plan is to upstream these changes to the Fetch spec. We have no interest in duplicating the spec or creating a separate one.
… We're discussing that with Anne, Fetch editor.
Andreu: The WinterTC test suite is a subset of Web platform Tests for the minimum common web API.
… Changes that may be needed will be upstreamed too.
Andreu: We want to collaborate with W3C and WHATWG. For WHATWG in particular, there's a strong focus on browser user cases.
… Does it make sense to have conformance levels for server-side runtimes?
… Sometimes, it's useful for editors and contributors to think about additional runtimes. E.g., during reviews.
… It would be good to think about considerations for these runtimes during TAG review, etc.
… Are there any barriers to this collaboration? E.g., IPR considerations?
… People making significant contributions in ECMA WinterTC also need to sign the contributor agreement of WHATWG.
Andreu: https://
nicolo-ribaudo: Regarding tests, do you plan a separate test suite for additional APIs?
Andreu: The CLI API is still very much work in progress.
… The common API is taking priority for now.
… It's hard to know what will happen for sure.
… If we need a specific test suite, we would very likely copy the same test harness in any case.
… It would seem better to contribute things to WPT in any case if that's possible.
kadirtopal: I'm from the WebDX CG. The minimum common API is prescriptive. How do you keep track of compliance?
Andreu: This will be prescriptive.
… We started by looking at existing runtimes and what they currently support.
… Once we have identified a test suite, plan is that these runtimes will follow them.
… We cannot force them to, of course.
… Example of having window be an EventTarget, we may allow exceptions for contexts where it would be impractical to do so.
… Node.js is very unlikely to adopt these standard events for instance.
… We allow that as an exception as a result.
aki: We acknowledge the environments in which the APIs got implemented.
Andreu: I'm looking at the spec that has wording around "legacy reasons" to behave differently.
… Such exceptions should not happen with newer runtimes.
michaelficarra: I like that you have conformance levels. Have you considered even more restricted ones such as compute-only?
Andreu: At some point, that might overlap with TC53.
… Targeted at embed use cases (e.g., no event loop).
… It's possible that there may be environments where it does not make sense to have fetch or setTimeout.
michaelficarra: I personally disagree but maybe we can sort this out later on.
Andreu: It's possible that the minimum Common API is too large for what should be the minimum.
… There might be good arguments to reducing that.
kadirtopal: Can we talk a bit about the audience? Implementors? Dev?
Andreu: So far we've been working with implementers mostly.
… TypeScript definitions that would contain the minimum common API is something that we've been discussing too.
… So both.
… We haven't looked too much into this but it's definitely in scope.
kadirtopal: In the WebDX CG, we have created a hierarchy of web-features, with implementation support in browsers, leading to the Baseline statuses.
… Have you considered leveraging the web-features catalog?
Andreu: I started to look into it. Something that we can discuss.
kadirtopal: That would be my proposal, that you reuse the same feature IDs to communicate to developers.
… We have mapped ~500 features in WPT. Goal is to have all features mapped to WPT soon, so you would be able to extract all the tests related to a feature.
michaelficarra: browser compat data also comes to mind as a source of support data
Michael: Wondering about the adopting modern features breakouts.
kadirtopal: Idea is to create a mapping from features to polyfills.
Michael: [missed]
Andreu: So far, we have been working with implementers to make sure that when we publish a yearly snapshot, that will work for them.
… Polyfills will be useful for older versions.
kadirtopal: Why is it called "Winter"?
Andreu: Acronym for Web-INTEroperable Runtimes.
… Now snowflake logo.
Michael: Wondering about interoperability for Bun
Andreu: Bun joined one session in WinterCG when we were talking about changes to the Fetch spec.
… My understanding is that the sessions are at a time when they can join.
Michael: I'm wondering whether they are moving in a direction that could cause interoperability risks.
Andreu: I don't know how much they match the common API.
… They also do a lot of things that are not web-like. They're probably not too conformant with it but they do have a subset.
… I haven't looked at this.
… Ideally, we'd like to have them and work together with them.
Michal: Wondering about JS that can run in both server and client runtimes. More and more, developers span the boundary. Have you discussed that?
Andreu: We have discussed that.
… My understanding is that there are some minor things in the [missed] that are not compatible with the server use cases, but that is something that we hope we can fix in the future so that we can adopt it.
… Re. Socket API, there have been attempts in WICG for TCP/UDP API that wouldn't be exposed to web runtimes directly. We're trying to align and collaborate.
Michal: One specific point is serialization when calling server functions. That's happening at the application layer. Wondering whether that's in scope?
Andreu: Not something that we're focusing on but interesting use case. I do want to move in that general direction.
Michal: Some client APIs that only make sense in the context of communicating with servers.
Andreu: So far, we haven't been looking into that.
… But interesting.
… We haven't looked at the communication between client and server.
Andreu: Thanks everyone for joining!
[session adjourned]