WinterCG to Standardize Browser APIs for JS Server Side Runtimes

A new W3C working group is setting out to standardize API implementation between web browsers and JavaScript server-side runtime environments such as Node.js, Deno, and Cloudflare Workers.

The web-interoperable Runtimes Community Group, WinterCG for short, has core contributors from Cloudfare, Vercel, Shopify, and several other web-heavy hitters. They want to standardize server-side APIs the same way browser APIs have been made uniform for developer sanity.

Server-Side Standardization

Standardization practices aren’t new. Working under the umbrella of the World Wide Web Consortium (W3C), the Web Hypertext Application Technology Working Group (WHATWG), established 2004, created the API standardizations for web browsers. Some of their work includes HTTP requests, Web sockets, URL Standardization, and Streams.

When it comes to implementing those same standards into server-side environments has been a bit slower.

Code practices differ between server-side environments and web browsers. What are the current solutions? Polyfill? Hacky code to just “make it work”? Creating new APIs? New middleware to adapt the API to fit the backend environment? WinterGC’s aim is to begin changing this.

Why Is This Important to Developers?

Flexibility. Modularized, portable code for the win.

As someone who doesn’t write code with the intention of migrating to a new environment but also never says never, I also wouldn’t turn down the idea of trying something new with the familiarity of home.

The majority of my work is coded in Node.js but for my most recent open-source product, I ventured into the unknown and developed in the Deno environment for the first time. There were ups and downs but there was definitely functional overlap. Uniformity in the functional overlap is something I greatly look forward to.

A great example of this disconnect in API implementation is in the Streams implementation in Node.js. The Node.js implantation is incredibly close to the WHATWG standardization and results in a faster data flow than other non-browser environments.

What WinterCG Is and What WinterCG Is Not

For WinterCG, “web-interoperable” means implementing features in a manner that are either identical or at least as consistent as possible with the way those features work in web browsers was very important for the group to make clear. So much so that it made it into the first half of their name.

In action, this means the URL() constructor will perform the same functionality in web browsers as it will in Node.js, Deno, and Cloudflare Workers. URL() will remain consistent and standardized across the stack.

An important purpose of adapting standardizations across the stack is to eliminate the need for each new environment to create their own APIs for common functionality. It is crucial to state that WinterCG will not create new APIs or their own set of standards that compete with existing standards set forth by WHATWG.

The group will not focus on adapting functionality from one environment to another. WinterCG’s scope will stay focused on adapting continuity between functions that exist in either web-based environments and Node.js, Deno, and Cloudfare Workers or the three server-side environments without the web-browsers.

In the event that a new specification idea emerges from WinterCG, the group will submit the idea to the WC3 and WHATWG for review. If there is no interest by WHATWG in moving forward, WinterCG has agency to move forward as long as there is no conflict with existing web standards.

Let’s Get It Started!

An important area to mention is Web Crypto Streams. The group is currently drafting a new Specification for Web Crypto Streams for consideration by the W3C as part of a larger effort to update the Web Cryptography Specification.

Cryptography is a sore spot for the developer community at large since the Web Cryptography API provides a minimal set of APIs for common operations. Other than Node.js, which is available as a built-in module, there is no support for streaming inputs and outputs to symmetric cryptographic algorithms. Subsequently, performance and scalability are limited. Hopefully WinterGC’s work will be impactful in this instance.

Fetch is another pain point of inconsistency. Web browsers and server-side runtimes implement Fetch. Due to the gaps between use cases on the front end and back end in fetch specifically, WinterCG is working on documenting a subset of the fetch standard to account for the narrower scope of each implementation.

There is also a minimum API list which can be found here.

Participation is open to everyone! The goals are ambitious and the group is just getting started. Members of the W3C, WHATWG, and JavaScript community large are encouraged to participate in the collaboration.