2026 WinterTC

WEH 2026 - WinterTC

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/88
• URL: https://meet.jit.si/WEH2026-wintertc

Andreu: work together to make sure server runtime cases are covered and get WInterTC to cover more API surface, as much as it make sense for server runtimes.

James: TC39 has a very clear process, a series of steps, we need our own process, we also need people to show up to participate in the process, how are runtimes going to participate and agree a way forward.

Andreu: we need to create an inertia for the process.If runtimes want wintertc to be a thing theycan leverage, they should work on it.

James: node has the leverage of being the main one but they are missing in the room (??). If we manage to work on the streams spec, we can ask "want do we want", but we need to have a structured conversation.

Christian: I don't need all the API nodes has, only a small subset, maybe I could have a smaller subset and make it faster (??).

James: is the common minimum api enough for you?

Christian: I would need to take a look; we need filesystem, for example...

James: that's the web files API, is that well structured enough? Is the work for WinterTC to do

Eem: I think you should look through the standard and annex b (??) and determinate what parts are the common minimum API, then go to TC39.

Andreu: Node wants certain APIs that they support

James: we cannot say what node wants or not, it's not something that they've ever done.

ANdreu: what wintertc can continue working and be relevant? For filesystem APIs, can seeking be done in the existing API?

??: seek is not supported, design of that API is a bit questionable (??)

James: there is work to be done, the question is: do we need more structure to do it? Web platform files api, for example, will people work in this to fix the API for server runtimes?

andreu: if the web has APIs but they are not great, we don't have a process to make a decision on what to do

James: node compatibility is a thing for most runtimes, i talked to the Tsc before and we had agreements, e.g. for buffers. For some apis, take the node apis and define a spec for them

Andreu: I don't think we should be doing that

Christian: depends on what it takes, as long as the apis make sense it's fine. We've seen more engines implementing js, some special purpose, etc. but in the future we'll have more engines, there can be some chance for those engines to optimize for wintertc use cases.

james: comes down to what runtime implements and they want to be compatible with node. But what does node compat mean? could there be a standard? it's not if you start doing imports and throwing errors.

??: I want deno to run node packages, for me that's the difinition of node compatible

James: what do runtimes need to do to support a minimum subset of it?

Ethan: we don't need to support the top 100 packages on npm but to prevent vendor lockin and have interoperability. Those companies sell JS hosting and clients demand no vendor lockin. These companies should be doing what browsers do because people don't want websites that run in one browser.

Andreu: the comparison with browsers may be up to something. On the one hand there's a parallel but with significant differences, main difference for me is that for over 10 years node was the only player in server runtimes, we had different hosts but they all run node. Even when there was a majority browser there were alternatives and a history where that major browser was not. For compatibility we would need to prevent many node idiosyncracies.

James: i think it's fine, we can very reasonably define a core minimum node API, things like buffer, a subset of buffers, but there are apis in node that doesn't make sense in other runtimes (workers). There is a threshold.

Titus: as an open source maintainer, I would like to exist a common api that I could stick to and be compatible with all runtimes.

Eem: I would also be able to be able to easily test if my package runs in all runtimes and I don't know how I could do it.

James: in node you need to go through 100 collaborators and other engines there can be one person deciding but it should be doable. If we start with a common api, we set a baseline, and then people from node can take a look and maybe want to change that and we can decide. But we have to set what are the minimum needs.

Joyee: I did a lot of analysis on the high impact packages; you can parse their code, find patterns, that could be a way to start.

??: on the topic of how to test across engines, there's a similar problem to test across browsers, similar problem space

Eem: a way to run a test suite on bun or deno would satisfy a lot of people

James: node discussed some time ago a way to create a conformance test suite to know if a runtime was compatible (when Microsoft was creating an alternative) but efforts fell short.

??: We (deno?) copied the test from node and ran them.

James: I think having an API is better as a way to conformance.

Ethan: wintertc calls have been unattended and we barely have any people showing up and making decisions. Node is not necessarily going to do the work on the compatibility suite but the work is already there, it's open source. We need someone to champion it, is that the goal of WinterTC?

James: I can produce the list of APIs that we feel are important, if deno can do the same it could be a way forward, a survey to inform a draft. we need participation, I should start participating regularly and we need more people showing up. If we are saying that's what everyone want to do I can start working.

Andreu: do we go with the socket api we have now?

James: the node socket api, the basic functionality is cool but it's insanely complex, we put together a very simplistic socket api that could be the minimum we need and it works, we can implement it on top of that.

Andreu: in the w3c are groups that extend the browser in several ways, e.g. isolated webapps, basically pwa with additional permissions, they basically had a socket api (not ours) some of those folks said they would have liked to work together, if we are extending the web in several ways we don't want to have several similar things that are incompatible.

James: it's not "here's this web api that you can use", e.g. it was not clear that web sockets was going to move forward, in the beginning it was just google pushing it. If we are going to work together we need to present all of our user cases and make sure they are covered.

????:

James: majority of users use a very specific set of apis, e.g.the filesystem api there are so many apis just in case, but 99% of usage is just like three functions. Something like buffer, we should have a minimum set of APIs.

James: to sum up, we need people!

Andreu: I might not be the right person to chair wintertc because i'm not involved in server runtimes anymore. Definitely, we need more runtime involvement.

James: for members of the community, voice what you want! It's cool, it's valuable. That helps shape what committees should be doing.

Eem: as I was saying in the beginning (no notes of that part), we need to have a place to post this kind of feedback.