Why JavaScript runtimes need their own standards body
Cloudflare, together with Vercel, Shopify, and individual contributors to Node.js and Deno, has announced the creation of a new W3C Community Group for JavaScript environments that run outside web browsers. The Web-interoperable Runtimes Community Group (WinterCG) aims to give server-side runtimes a formal venue for shaping the web APIs they implement.
The W3C and WHATWG have long produced the standardized APIs that make the modern web work, including fetch(), ReadableStream, URL, URLPattern, and TextEncoder. But their charters restrict them to considering only what browsers need. That narrow focus creates problems for everyone else. The Streams standard is a case in point: several non-browser implementations of it are an order of magnitude slower than equivalent Node.js or Deno streams, largely because of how the specification is written.
Non-browser environments have requirements that simply don't apply to browsers. Serverless platforms like Cloudflare Workers have no local file system, while Node.js and Deno expose one fully. Browsers enforce CORS and origin-based security; servers have no equivalent concept. When the specifications don't account for those differences, each runtime ends up building its own ad-hoc solution for functionality that is actually common across environments. WinterCG is intended to change that by advocating for the requirements shared by all web environments.
Portability as the goal
For developers, the pain is real. Code written for one runtime often needs significant rework to run on another. A frequent complaint from Cloudflare users is that an npm module relies on Node.js- or Deno-specific APIs, forcing them to assemble a patchwork of polyfills. Deno has taken a different approach by bundling a polyfill of Node's core API directly into its standard library.
The goal is simpler: where environments overlap—cryptographic hashing, streaming, HTTP requests—they should implement the same standardized mechanisms. That way, code written once can run wherever the developer chooses, without a rewrite.
That said, the name "web-interoperable" is deliberate. "Web" is used exactly as the W3C and WHATWG use it, meaning web browsers. Interoperable means implementing features identically, or as consistently as possible, with browsers. The new URL() constructor in Node.js should behave exactly as it does in a browser. But WinterCG also acknowledges that Node.js, Deno, and Cloudflare Workers are not browsers, and the differences matter for API design.
WinterCG is not intended to publish a competing set of standards. New proposals will first go to existing W3C and WHATWG work streams. Only if browsers show no interest in a feature that other environments need would WinterCG move forward with its own specification—and even then, nothing it produces will intentionally conflict with established web standards. Participation is open, and all work will happen publicly in the wintercg GitHub organization.
Early work items
Minimum Common Web API
The group has begun drafting a curated subset of existing web platform APIs that should behave consistently across Node.js, Deno, and Cloudflare Workers. Most of the selected APIs already exist in these environments; the work is in making their implementations conformant to the relevant specifications and portable across runtimes. Where an environment deviates—like Node.js's setTimeout() and setInterval()—the differences will be documented, and such deviations should exist only for backward compatibility.
Web Cryptography Streams
The Web Cryptography API has a notable limitation: unlike Node.js's built-in crypto module, it offers no streaming support for symmetric algorithms. All operations work on chunks of data held entirely in memory, which hurts performance at scale. WinterCG has started drafting a specification for Web Crypto Streams that would bring streaming crypto operations to the entire web including browsers, and plans to submit it for consideration as part of a broader W3C effort to update the Web Cryptography specification.
fetch() for the server
Node.js 18 added a fetch() implementation, joining Deno and Cloudflare Workers. But server-side fetch() differs from the browser version. There is no origin concept, no CORS, and no global cookie store. Those differences make it hard to reason about changes to the fetch standard when some proposals are highly relevant to servers but useless to browsers.
WinterCG is documenting a server-focused subset of fetch that addresses these constraints. The subset is fully compatible with the fetch standard and is being developed cooperatively by the maintainers who implemented fetch() in each of the three runtimes. It will not be a competing definition of fetch, but a guideline for implementing it correctly in non-browser environments.
The group's work is early, and participation is open. More details are available at wintercg.org, and instructions for joining are in the wintercg/admin repository.
