WinterTC: the ECMA Web-interoperable Runtimes Technical Committee

Javascript runtimes

Environments that run Javascript and provide a way for it to do I/O

Web browsers can be considered Javascript runtimes

Server-side Javascript runtimes

Javascript runtimes that are used as servers

• Some are general purpose OS processes, typically offerring a CLI, but they’re often used as servers (e.g. Node.js, Deno…)
• Others are edge runtimes running in the cloud, which only support server use cases (e.g. Cloudflare Workers, Deno Deploy…)

Web-interoperability

Web-interoperability

Why care about it?

• More code reuse
• Less “polyfills” (e.g. isomorphic-fetch)
• Learn once, write anywhere
• Common documentation (MDN)
• Reduced lock-in

The web platform is the largest and most important development platform in the world

Web-interoperability

• Many server-side runtimes already have some degree of web-interoperability
• But the differences with browsers matter for web API support
  • Web specs are written for browsers to follow
  • If each runtime solves these issues independently, we have new sources of incompatibilities
• Extending/using web APIs in ways that aren’t a priority to browsers
• All of which require a venue for coordination between server-side runtimes and with web specs

Cross-runtime interoperability

Server-side runtimes also have common needs which are different to browsers...

• HTTP server API
• CLI and environment variables API
• Networking protocols which are not supported as web APIs (TCP/TLS/UDP/QUIC...)

Cross-runtime interoperability

While some of these needs could be supported in specialized web environments (e.g. PWAs), some are very unlikely.

We need a venue to expand the common baseline of functionality available in all runtimes, for things both in and out of scope for the web platform.

WinterCG and moving to Ecma

• WinterCG started out as a W3C Community Group
• Allowed open collaboration without membership requirements
• Unable to publish technical reports or standards
  • Very relevant for us because we were working to publish various specs

WinterCG and moving to Ecma

• Mid-2024 we started looking for a new standardization venue
• Quickly found two options:
  • W3C Working Group
  • Ecma Technical Committee
• We had good discussions with both W3C and Ecma
• Major points of interest for us:
  • Invited expert policy, to continue open collaboration
  • Simple organizational structure
  • Organizational help

So what are we working on?

• Minimum Common Web API, defining the common subset of web APIs that should be available everywhere
• WinterTC test suite, identifying a subset of WPT that matches the Minimum Common API
• Sockets API, to enable a unified API for TCP and TLS sockets everywhere
• CLI API, to enable unified access to env vars, args, cwd etc.

So what are we working on?

We are also working on contributing to upstream specs:

• Fetch: servers do not need browser specific security features (cross-origin restrictions...)
• Web Crypto: adding support for streaming data

Minimum Common Web API

A minimal set of APIs that should be implemented by all web-interoperable runtimes

• A superset of [Exposed=*] APIs
• Meaning many compute-only APIs such as URL or URLPattern
• Additionally general purpose async I/O APIs like fetch or setTimeout

We’ll be publishing yearly snapshots (first one in Dec 2025)

In the future: conformance levels

The Minimum Common Web API is the minimum that all runtimes should support

Additional possible targeted conformance levels:

• Graphics, with headless WebGPU, OffscreenCanvas, Image, DOMRect...
• CLI/File System, including FS APIs, envs, args
• Servers, including advanced networking APIs (TCP/TLS/UDP/QUIC), and HTTP server APIs

Fetch

Differences from browsers:

• There is no current page
  • Thus no origin
  • Thus no cookie jar
  • Thus no referrer
• No need to protect against cross-site requests since no authentication information is provided by default
• No need for atomic redirect handling
  • Proxy servers need to be able to see redirects happening

Fetch

Standardizing these differences

• We have identified some places that would need changes to the spec to support server-side runtimes (WinterTC55/fetch-workstream#1)
• The plan is to make those changes upstream
  • We’re not interested in forking the Fetch spec
• We would probably have to add “feature flags” / conformance classes
• Pending to discuss exactly how to do this with the Fetch editor

WinterTC test suite

A standard is worth little without a test suite.

• We are working on identifying a subset of WPT that tests the Minimum Common Web API
• The WinterTC test suite also should only rely on the Minimum Common API, while testing everything in it, so sometimes we need to modify tests
• As with fetch, the goal is to make any changes upstream
• For additional levels on top of the Minimum Common Web API, we could add custom additional tests

Collaborating with W3C/WHATWG

• WHATWG is heavily focused on browser use cases, does it make sense to have conformance levels for server-side runtimes?
• How do we get spec authors and contributors to consider server-side runtime use cases?
• Are there any barriers to this collaboration? How can we work to fix them?