wintertc logo

WinterTC

Technical Committee on Web-interoperable Server Runtimes

What is WinterTC?

The Technical Committee on Web-interoperable Server Runtimes (WinterTC) is a community of people who are interested in interoperability across server-side (Deno / Node.js) or edge JavaScript runtimes (Cloudflare Workers / Deno Deploy), especially for Web Platform APIs.

WinterTC is organized as Ecma International's Technical Committee number 55 (TC55). This gives the group access to Ecma's vast infrastructure and its IPR policy work, as well as the ability to publish standards. This is the same type of committee as TC39, which standardizes the JavaScript language.

What are we trying to do?

The ultimate goal of this committee is to promote runtimes supporting a comprehensive unified API surface that JavaScript developers can rely on, regardless of whether their code will be used in browsers, servers, or edge runtimes.

It is another goal of WinterTC that runtimes with needs for capabilities beyond web platform APIs, in particular server-side and edge runtimes, still have unified surfaces.

The members of the committee want to provide a space to better coordinate between server-side implementors, as well as with browser vendors, on how to best achieve this interoperability.

It is not explicitly a goal of WinterTC to promote such a unified API surface for other JavaScript environments, such as embedded applications. However, the results of our work could be useful to such environments nonetheless.

How do we want to achieve our goals?

We want to specify and document how server side runtimes can best implement Web Platform APIs and to what extent they could deviate from browsers.

We want to provide feedback to spec authors of Web Platform APIs from the view point of non-browser runtimes to help them make informed decisions about future changes and additions to these specifications.

We want to develop and specify new APIs that, although they might be too powerful for the Web Platform or not fit within its security model, would still be a great fit for server-side runtimes and would be part of a comprehensive unified API surface for such runtimes.

Why are we doing this?

The members of this group all share the belief that a comprehensive unified API surface for JS runtimes is something that would benefit the JS community as a whole. In the past members have individually worked on making this a reality.

This disparate approach with little coordination has historically led to much confusion between not just browser vendors, spec authors, and other implementors, but also between non browser implementors and other non browser implementors on topics of unified API. This was often caused by the fact that discussions were spread over various disparate issue and PR comments with often little context or cohesion between them.

We think that by working together more tightly we can provide browser vendors and specification editors with more meaningful feedback from users of non-browser JS runtimes. This will help them make informed decisions about future specification changes that relate to the goal of a comprehensive unified API surface for JS runtimes.

What are we NOT trying to do?

We do not want to fork or create new versions of existing specifications. If we think a new web platform API is needed, or if we think an existing spec needs changes, the goal is always for that change or addition to be developed in an existing venue (such as WHATWG or W3C). WinterTC will publish requirements on what those changes could be, and it will be up to that existing standards body to make these changes, possibly through members who are part of both WinterTC and that standards body.

We do not want to create new server-side APIs that overlap with existing web platform APIs. If there is a proposed or standardized web API that overlaps with the needs of server-side runtimes, the goal is always to investigate what changes (if any) it would need to be useful for servers; and once those changes have been incorporated to the specification, to eventually add the API to the minimum common set.

We are not trying to shift the focus of Web Platform APIs to only serve server-side runtimes. We want to see more API surface that is useful and works great both in browsers and on the server.

Is this the same as “WinterCG”?

We initially started our work of working on this cross-runtime interoperability in May 2022 by creating the Web-interoperable Runtimes Community Group (nicknamed WinterCG) under the W3C. We chose to organize it as a W3C Community Group because it was open for anyone to participate, without needing to be a W3C member.

W3C Community Groups are set up to help people organize together, but they can't publish standards. And as WinterCG matured, and our goal expanded over time to include defining non-web APIs, it became clear that we needed to form some working group or technical committee, which can publish standards. Therefore, in December 2024 we formed WinterTC (formally, TC55) as an Ecma International Technical Committee. When WinterTC is fully set up, all WinterCG work will move there, and then WinterCG will close.

You can still be involved in WinterTC, but in order to become a member of it, you need ...

By their very nature, Ecma TCs are not as open as W3C CGs, requiring participants to either belong to an Ecma member or be an invited expert. However, keep the spirit of openness, we plan to invite anyone who does not belong to an Ecma member as an invited expert, so that anyone is free to participate.

Who controls WinterTC?

WinterTC is controlled by the community of people who are working in it. The chair(s) of the group help moderate discussion and help guide the group towards consensus on proposed changes.

Currently the group consists of individual members, and members from the following organizations:

  • Bloomberg
  • Cloudflare
  • Deno
  • Igalia
  • Node.js

How can I participate?

The work of WinterTC happens openly on Github, and most of the discussion and conversation around it happens inour Matrix room. You're welcome to participate in both of them.

Only members of WinterTC can participate in WinterTC meetings, though. In order to be a member of WinterTC, you need to be a representative of an Ecma member, or an Ecma invited expert. However, if you don't fulfill those requirements and still want to become a member, you can ask to become an invited expert here.