Room 406: This session is about WinterTC, which is the ECMA Web Interoperable Routing Technical Committee. We'll be going through what each of those things mean. ECMA, I guess that doesn't need too much introduction. It's, standards body, standardizes JavaScript, and, but we will be looking more about why we work with ECMA, but yeah, we'll look at those, some of those things. So, JavaScript runtimes. These are environments that run JavaScript and provide a way for you to do input-output. Like, unlike say, the C language specification, which does have a sender library that gives you a lot of tools to do input in the operating system, the JavaScript specification gives you almost nothing, and it's... I mean, the goal is for runtimes to provide it on top of the specification. And, I would consider web browsers to be JavaScript runtimes. It's just the part of the I.O. that they do is… like giving you the DOM, which is a way to represent things in a graphical, screen. It's not actually drawing pixels to the screen, but it's I.O, and you could also do I.O. with network requests.

Room 406: Server-side. JavaScript runtimes that are used as servers. Not necessarily that are only meant to be used as a service, because, Node.js, Deno, and so on are general, really general purpose OS processes. They give you basically everything that you need to be able to do almost anything in the OS. They typically give you a CLI, but because of historical convenience and to some extent performance reasons, they're often used as servers. Part of the history of this is that, having an event loop environment with JavaScript, with all of the tools that JavaScript provides you, especially when looking at the web and async.io and all of these async operations, especially when Node.js came out in 2009, it gave you, a huge advantage over a traditional server, as the traditional server architectures would use threads, and when you have a lot of requests, that was fast. Some other server-side JavaScript runtimes are edge runtimes running on the cloud, which basically only supports server-side use cases. You do a request, it runs the JavaScript code to handle that request. And then, it basically… moves on to do, like, to handle a different request, or basically destroying the JavaScript context, or maybe reusing it, but not, like. Well, yeah, it's basically, only meant for server-side use cases, and it's not meant to keep storage in the runtime.

Room 406: Examples are Cloud for Workers, Deno deploy, and the fact that Deno Deploy, like, Deno is a general-purpose OS process, and deploy is an edge runtime. You also see this with Node.js and, and various Node.js-based, edge runtimes. It's… like, a lot of the functionality used as servers in general purpose OS processes can be adapted for its runtime, so it makes sense to work, like, to treat both of them together in some sense.

Room 406: And, web interoperable server-side runtimes. It's about interoperability with browsers and the web. Why would a server-side runtime care about web interoperability? Unless you reuse more code, the web platform is so ubiquitous, so common, that you probably want to... It's very useful to be able to write some code and run it in the client side, in the server side. If the runtimes are not web interoperable, you need polyfills, such as isomorphic fetch, which is no longer needed, because in recent Node.js versions, you have fetch implemented in Node with, with Undici. But, yeah, this additional web interoperability in the runtime, reduces the need for polyfills. It lets you learn once and write some code that will work, everywhere if you only use this set of web interoperable APIs. It has an awesome common documentation. Huge props to Open Web Docs for maintaining MDN, which I guess we all use to some extent. And, yeah, having this reduces locking, because the more code you can reuse, the less you're gonna have to rewrite your app to port it to a different server-side environment that is also web interoperable.

Room 406: And in general, the web platform is the largest and most important development platform in the world, and it makes sense to use it. Yeah, to make use of this.

Room 406: Many server-side programs already have some degree of web interoperability, as I was saying, with Fetch in Node.js, but sometimes there are differences with browsers that do matter for web API supports. Web specs are written for browsers to follow. And, let's say, one very simple example is, if you pass a relative URL to fetch, go fetch with a relative URL. In browsers, it is resolved to the current page URL. That has an equivalent in server-side runtimes. Deno lets you pass in a flag to set a location href, but, other than that, and by default, in other server-side runtimes, you don't have an equivalent. In this case, most, I believe, most server-side runtimes throw because it's the only sensible thing that they could do. But for other things, it's not as clear. And if you try and solve these issues independently, now we have new sources of incompatibilities across them.

Room 406: And, sometimes, server-side runtimes want to use web APIs, or sometimes extend them in ways that maybe would be fine for browsers, would fit in the web platform, but aren't such a high priority for browsers. But they are a high priority for server-side programs. And all of this, together basically requires a venue for coordination between server-side runtimes and web specifications.

Room 406: But, of course, server-side runtimes have common needs that are not in common with the web platform. There is building the de facto standard for an HTTP server API, but there's still some incompatibilities there. It seems like there's a clear need for a CLI and Environment Variables API, which each runtime currently doing its own thing, and there are networking protocols that are currently not supported as web APIs, maybe they're lower level, which would be really useful to have in server-side runtimes.

Room 406: And some of these needs could be supported in specialized web environments, such as progressive web APIs. This is progressive web application, sorry. This is especially the case for these networking protocols, maybe not allow them in the web as a whole, but in specialized environments. But CLI and environment variables, that is not going to happen. That is not going to be part of the web platform. So we need a venue to expand the common baseline of functionality available in all server-side runtimes for things that are in scope of the web platform and not out of scope of it.

Room 406: In May 2022, engineers from Dino, Cloudflare, Igalia, and other companies involved in server-side runtimes created WinterCG. This was a W3C community group. And we did this in this way as a community group to allow open collaboration with our membership requirements. This was very relevant because most, folks involved in the server side runtimes are not actually members of W3C. And the problem with this is that a community group cannot publish technical reports of standards, and this was very relevant for us because we were looking to publish various things for server-side things. Halfway through last year, like, mid-24, we started looking for a new standardization venue. And we considered W3C Working Group and an ECMA Technical Committee. And we had both discussions with both, but some of the major points of interest for us were to have an invited expert policy, that would continue open collaboration. This common to both W3C and ECMA. But there are some details about the differences here. To have a simple organizational structure, having organizational help to set up the TCU or the working group. And, one factor that I'm not listing here is that, a number of the members of WinterCG that, like, many were not members of W3C and ECMA, but a number of them were members of ECMA because they were participating in JavaScript standardization.

Room 406: In the end, we basically decided to, shut down Winter TC, WinterCG, and, form instead ECMA Technical Committee number 55, aka WinterTC. The fact that we had to shut down WinterCG was something that we… was a side effect of this, because, a CG wouldn't, like, in W3C, CG can move draft specs into, a working group, but moving them across organizations was tricky, especially... For doing it once, moving things that were in WinterCG, moving them to Winter DC is fine. Moving them all the time, that is not fine. And, so we're currently, basically, relying on having a bunch of invited experts on the ECMA to cover this.

Room 406: It's what we have to do, I guess. So what are we working on, currently? We have the minimum common web API specification. This defines a common subset of web APIs that should be available everywhere in server-side runtimes. We have a WinterTC test suite, that we are working on, that is basically a subset of WPT that matches the minimum common API, and we are also working, with less priority on, two specs for sockets, to have a unified API for TCP and TLS sockets, and a CLI API to have a unified access to environment variables, arguments, the current working directory, and so on.

Room 406: And we are also looking to contribute to upstream specs, like Fetch, I mentioned earlier the passing a relative URL, but servers don't need some browser-specific security features, such as cross-origin restrictions, because there is no concept of origin in the server. And we're also looking to add support for streaming data to the Web Crypto API.

Room 406: And for the minimum common web API, this is supposed to be a minimum set of APIs that should be implemented by all web interoperable runtimes. This, should be a superset of Exposed=*. Which would by itself include many compute-only APIs, such as URL, URL pattern, but the plan is to also, include general-purpose async I.O. APIs, like fetch() and setTimeout(). This is meant to be a minimum base, that… and then… Yep.

Room 406: We will be publishing yearly snapshots for this, with the first one currently in progress to be published in December. I'm working with Aki to finally finish all of the editorial details. In the past few days, it's been hectic.

Room 406: In the future, the plan is to have some conformance levels, with the minimum common API as the base, is the minimum that all runtimes would support, and then we have, additional, possible targeted conformance levels on top of it, such as graphics for, headless WebGPU, or screen canvas, and so on, CLI and file system level, also sitting on top of the minimum common web API. And if we consider browsers as implementing the minimum common web API, then you could… we could also have a server level, on top of the minimum web API with the various advanced networking APIs, the executable server APIs, and...

Room 406: For fetch, some of the differences from browsers, I've hinted on this previously, but there is no current page, so no current URL, no origin, no cookie jar, no referer. All of this is stuff that the fetch specification assumes that it exists. There's also no need to protect against cross-site requests, since, there's no authentication information provided by default. There are no… there's no current cookie jar, so, network requests aren't automatically populated with cookies. And there's also no need for atomic redirect handling, and this is relevant for proxy servers, because they need to be able to see where it's happening.

Room 406: And, we have identified some places that would need changes in the spec to support server-side runtimes. We have this issue in the Fetch-Workstream repo for Winter TC. The plan is to make those changes upstream in the fetch spec. We're not interested in forking it. This is something that we have previously considered, and we decided that it was not a good idea at all. And we would probably need to have some feature flags or conformance classes in the fetch spec. To say, like all of these origin restrictions only apply if you're a browser, and not if you're a server audience. And we're planning to discuss exactly how to do this with Anne, which is the Fetch editor, and this is still a work in progress.

Room 406: A standard is worth little without a test suite, so we're working on identifying a subset of WPT to test the minimum common web API, and it should also only rely on the minimum corner API, like you want the test should not assume that other stuff exists, because they might not be able to be tested in those environments. It's possible that we might need to modify tests that are currently relying on some of the APIs. This is common, for example, for structureClone, definitely. There are many, like, if you want to test whether, image, or DOM Rect, or whatever, are structurally clonable, those should be guarded on the existence of those APIs, so that they can run in environments that don't have them. As with Fetch, the goal is always to make the changes upstream. And for additional levels on top of the minimum common web API, we could add an additional custom test suite, but this is to be, like, we'll figure this out in the future.

Room 406: We want to collaborate with W3C and WHATWG. This is one of the huge points of WinterTC. So, W3C in particular is heavily focused on browser use cases. To be fair, the HTML spec does have some conformance levels that are not browsers. Room 406: But 100 to what extent does it make sense to have conformance levels for server-side runtimes? Would this make sense in Fetch? How would the process work? Like, sometimes it's useful to get spec authors and contributors to consider server-side runtime use cases. Like, the W3C has TAG, which has a horizontal review, and maybe they can point out, or there are various other kinds of horizontal review, but they can point out: it would be good if, rather than doing this on your own, you looked into this, relevant use case and so on, and sometimes, there can be relevant server-side runtimes use cases, and maybe it's better to, maybe there are cases where working together there is useful. And are there any barriers to this collaboration? IPR, for example, we're working on figuring out all of the the requirements about contributing to Fetch as part of our ECMA TC and it seems like everyone, who has done some significant contribution to our decision on… on what changes we should make to the Fetch spec should also, sign the WHATWG Contributor Agreement. Are there any other barriers, and how can we work to fix them?

Room 406: And, this is, this is it for the presentation. We're, like, our website is WinterTC.org. We have the WinterTC 55, GitHub organization. Like, WinterTC was taken, and it's TC55, winter… And, we have a Matrix room. This is actually the… the organization and the matrix Room are reused from the Winter CG ones, which is renamed them. I'll open the floor for discussion.