WinterCG

What is a JavaScript runtime?

• JS spec (ECMA-262) defines no I/O
• JS is designed to be a scripting language embedded in a larger system
• The system provides a set of APIs to interact with it – a runtime environment
• Some such environments (like Node.js, Deno, Bun…) only exist to give the JS code access to I/O

Types of runtimes

• General purpose OS process: Typically offer a command-line interface. They’re mostly used as servers, in which case every request runs in the same instance. E.g. Node.js, Deno...
• Edge runtimes: Essentially only support server use cases. Typically different requests run in different instances. E.g. Cloudflare Workers, Deno Deploy...
• Browsers: JS is used to control a GUI, and sessions are long-lived. Different sessions (pages) can run in the same instance if they’re same-origin.

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, including Node.js
• 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 required a venue for coordination between server-side runtimes and with web specs

The Minimum Common API

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

  • “WinterCG-compatible” (we don’t define that term though)
  • A superset of [Exposed=*] (ShadowRealm web integration)
  • Will grow in the future
• A target to write code against
• In the future it might include requirements about exact WebIDL implementation, or ESM host hooks

WinterCG’s various efforts

Contributing upstream to web specs

WinterCG’s various efforts

Wider work in common with the web platform

• Fixing the fetch spec to support server-side runtimes

  • Server-side runtimes have no cookie jar, no origins...
  • Different conformance classes?

• Web integration of AsyncContext

  • Server-side runtimes have specific needs (tracing, associating code to an HTTP request…)
  • Taking their needs into account when proposing a solution

WinterCG’s various efforts

Server-side specific APIs

• Sockets API (TCP connections)
• CLI API
• Runtime keys

Standardization

• WinterCG is currently a W3C Community Group: less friction for joining, can incubate specs, but can’t publish them
• Our browser-compatible efforts would be graduated to a Working Group (fetch & streams to WHATWG, WebCrypto streams to WebCryptoWG)
• What about Minimum Common API and other server-side specific specs?

• We’re considering moving WinterCG to Ecma

  • What about our browser-compatible efforts?
  • We want to continue working together with W3C/WHATWG.

Collaborating with upstream

• W3C and WHATWG seem heavily focused on browser use cases, will only accept changes if they make sense in browsers

  • Is it “speci-fiction” if there are non-browser implementers?
  • Can we have different conformance classes?

• How do we get spec authors to consider server-side runtimes?

  • TAG?
• Are there any barriers to this collaboration? How can we work to fix them?

The end

https://wintercg.org

https://github.com/wintercg

Matrix room