The WinterCG community was officially established, and the front-end code can finally run on the back-end

On May 9, Cloudflare announced on its official blog that it will work with core contributors to the Node.js and Deno open source projects to establish a new community group named WinterCG (Web-interoperable Runtimes Community Group), which brings together The three largest JavaScript environments, giving developers flexibility and choice while creating the future standard for edge computing. Delivering on the promise of “write once, run anywhere” through a common set of standards that allow writing portable applications in Node.js, Deno, and Cloudflare serverless environments while eliminating the need to rewrite code.

Cloudflare co-founder and CEO Matthew Prince said, “This is a feat that was previously unattainable. JavaScript is being used by millions of developers and is the first language the average developer learns. So far, JavaScript standards are entirely focused on the front end, such as the browser.” Matthew Prince added, “By standardizing the core JavaScript API, taking into account both the front end and the back end, this empowers front-end developers to do more in a familiar way. Easy access to the backend.”

In response to this news, we interviewed Deno’s core contributor, justjavac (Midu), who said: “This community should have been established! This allows cloud computing or edge computing platforms to provide APIs that are consistent with the Web, rather than developing independently. Its own API. For community developers, there is no need to learn an additional set of APIs, and they can deploy to different platforms by writing a set of code.”

What was the original intention of the WinterCG community?

According to Cloudflare’s official statement, the essence of the WinterCG community group is to provide a space for the JavaScript runtime to collaborate on API interoperability. This collaboration generally includes three aspects: discussions between runtimes; proposals for Web APIs in existing specification communities (WHATWG, W3C), including existing and new proposals; refinement and maintenance of existing runtimes Documentation of behavior.

In this regard, justjavac believes that when Node.js was released, there were not so many Web API specifications, so Node.js designed a server-side API, which was directly reused at the beginning of the design. Web API, most JavaScript developers are very familiar with these APIs, such as fetch, URL, TextEncoder, etc. The WHATWG has since developed many Web API specifications, and recent versions of Node.js have also started adding WHATWG-compliant APIs.

However, these Web APIs cannot be implemented on the server side 100% according to the standard. After all, Web standards are formulated for browsers. If each server-side runtime is adjusted in its own way, the end result is that the code can only run in a specific On a certain platform, this is also the original intention of Cloudflare to set up WinterCG.

It is not difficult to see that the newly established WinterCG will focus more directly on the implementation of the specific needs of non-Web browsers, complementing existing community organizations that currently focus on Web platform functionality and API development. WinterCG’s goal is clearer: focus on implementing these same features in environments like backend servers, serverless computing, IoT, command line tools, and more.

Serverless environments like Cloudflare Workers, or runtimes like Node.js and Deno, have a wide range of problems and different requirements that are not related to web browsers and vice versa. Ultimately, the disjointness and absence of these differentiated requirements when developing various specifications has led to a situation where non-browser runtimes have implemented their own custom, ad hoc solutions already running on various in a production environment.

The WinterCG community was formed to change these issues, providing a place to discuss and advocate for the common needs of all web environments, deployable anywhere in the stack. For developers, code portability is very important, and if you write a set of code and want to migrate it to run in a different environment (eg, from Node.js to Deno), you should not want to Completely rewrite it?

Cloudflare Workers, Node.js, Deno, and web browsers are all very different, but they share a lot of common functionality. For example, they both provide APIs for generating cryptographic hashes; they both handle streaming data in some way; they both provide the ability to send an HTTP request somewhere. If there is overlap, and the requirements and functionality are the same, then the environments should all implement the same standardization mechanism.

So, by developing a set of common standards, WinterCG allows developers to only care that the code they write will run properly, no matter where the code runs.

WinterCG: Not planning to release a separate set of standard APIs

According to reports, the new WinterCG community group will operate under the established process of the W3C.

As you can see from the group’s naming, the key point is “web-interoperable”. According to the official explanation, the meaning of “web” used here is exactly the same as the term used by the W3C and the WHATWG community. A “web browser” to be exact. Thus, the term “web-interoperable” means implementing functionality in a way that is the same as, or at least as consistent as possible, a web browser. For example, the new URL() constructor works exactly the same in browsers as the new URL() constructor works in Node.js, Deno, and Cloudflare Workers.

It’s important for WinterCG to acknowledge the fact that Node.js, Deno and Cloudflare Workers are explicitly not web browsers. While this is obvious, it’s worth pointing out because differences between the various JavaScript environments can greatly influence design decisions for standardizing APIs.

In this regard, the official example, Node.js and Deno provide full access to the local file system. By contrast, Cloudflare Workers have no local file system; and web browsers necessarily restrict applications from operating on the local file system. Likewise, while web browsers inherently include the concept of a website “origin” and implement mechanisms such as CORS to protect users from various security threats, in Node.js, Deno and the server-side operations of Cloudflare Workers do not have the same ” origin” concept.

So far, both the W3C and the WHATWG have paid close attention to the needs of Web browsers. WinterCG, the new web interoperable runtime community group, will explicitly address and advocate for everyone’s needs.

In this regard, WinterCG also stated that it does not intend to release a set of independent standard API sets. Ideas for new specifications published in WinterCG are also first submitted to the W3C and WHATWG for consideration to gain and achieve more consensus. However, WinterCG will be authorized to push forward with its own published specifications if the web browser has no specific requirements for the functionality required by other environments (such as Cloudflare Workers). The premise constraint is not to intentionally introduce content that conflicts or is incompatible with established Web standards.

Minimal Generic Web API

“The Minimal Generic Web Platform API is a carefully designed subset of the Standardized Web Platform APIs to define a minimal set of functionality common to browser and non-browser JavaScript-based runtime environments.” This is the current draft specification introduce.

In other words: it is a minimal set of existing web APIs that will be implemented consistently and correctly in Node.js, Deno and Cloudflare Workers. Most of the APIs (with some exceptions and nuances) already exist in these environments, so most of the work that remains is to ensure that these implementations conform to their relevant specifications and are portable across environments.

Every time an environment deviates from the standardized definition of an API (such as Node.js’s implementation of setTimeout() and setInterval() ), there is clear documentation describing those differences, says WinterCG. And this difference should only exist for backward compatibility with existing code.

In addition to this, WinterCG has now started drafting a new specification for “Web Crypto Streams” and submitted it to the W3C for consideration. The Web Cryptography API provides a minimal and very limited API for common cryptographic operations, and one of its main limitations is that it differs from Node.js’ built-in crypto module. Deno is directly implemented according to the web crypto specification, and the built-in crypto module of Node has been developed very early. This time, the specification is formulated according to the existing implementation of Deno and Node.js, which will be more convenient for the implementation of other platforms in the future. with normalization.

js, Deno, and Cloudflare Workers currently implement fetch() in a number of important ways from how they are implemented in web browsers, and to make it easier for non-web browser environments to implement fetch in a consistent way, WinterCG A subset of fetch is being written to specifically handle those different requirements and constraints. This subset will be fully compatible with the fetch standard, and was co-developed by the same people who work on fetch in Node.js, Deno, and Cloudflare Workers. This is also not going to be a competing definition of the fetch standard, but rather a set of documented guidelines on how to properly implement fetch in other environments.

WinterCG: We’re just getting started

According to WinterCG, the Web Interoperable Runtime Community Group is just getting started, and they have many ambitious goals. Anyone can participate, and all work will be done publicly via GitHub at https://github.com/wintercg . Currently, WinterCG is actively seeking collaboration with the W3C, WHATWG and the entire JavaScript community to ensure that web functionality is available, works consistently, and meets the requirements of all web developers working anywhere in the stack, in everything it does Will aim to maximize interoperability.

Finally, I would like to thank teacher justjavac (Midu) for her professional views and guidance on this article.

Reference link:

https://wintercg.org

https://github.com/wintercg/admin

https://blog.cloudflare.com/introducing-the-wintercg/

https://www.w3.org/community/wintercg/

https://deno.com/blog/announcing-wintercg

The text and pictures in this article are from InfoQ