The Web Beyond Browsers
Web standards aren’t exclusively about facilitating cross-browser consistency. The standardization of web platform APIs beyond the browser is coming, and I’m here for it.
Here’s a few links that have been solidifying this idea in my head as of late.
This container isn’t meant to address the same breadth of problems that Linux containers target. Its emergence is a result of its simplicity. It minimizes the boilerplate for web service business logic. It shares concepts with the browser and reduces the concepts that the programmer needs to know…
On top of all that, there’s the benefit of universality:
The fundamental mistake of Node.js was diverging from the browser as new APIs were standardized, inventing too much. In 2010, we didn’t have ES modules, but once it was standardized it should be been brought into Node. The same can be said for promises, async/await, fetch, streams, and more. Antiquated non-standard bits like CommonJS require, package.json, node_modules, NPM, the global process object will ultimately either be standardized and added to the browser or supplanted by web-aligned replacements.
I think the same way people like Zeldman helped surface the need and importance of building for browsers with web standards, we’re seeing the same thing happen for browser-adjacent technologies, like servers. Bet on standards!
Which leads me to today’s announcement of the “Web-interoperable Runtimes Community Group (WinterCG)”. From the Deno blog:
when using Deno, you aren't learning new platform specific APIs or functionalities, but rather you are investing in your knowledge of the largest, and most important platform in the world: the web.
It's not all sunshine and rainbows, though. Many web platform APIs were designed with only the browser in mind, and not server side runtimes. This means that when server side runtimes implement these APIs, they sometimes have to diverge subtly from the browser implementations and specifications, so the API becomes useful on the server. A great example of this is
fetch: the API surface itself works fine on servers, but only when CORS is skipped, users can manually handle redirects, and full duplex HTTP streams are supported.
Indeed, there are tricky divergences for APIs originally made for browsers which are now being ported to server environments. Personally, I learned about these deep-rooted nuances of
fetch the hard way: through trial and errors while trying to make a CORS proxy on the server and running into redirect status codes.
These subtle differences in API behavior exist for all server side implementations of fetch, but are often not well documented, and not consistent across runtimes. To fix this, engineers from Deno, Cloudflare, and a couple of other companies came together to discuss how we could solve this problem. We want to make server side runtimes consistent and compatible with each other...
I love the emphasis on surfacing these bumps in web platform APIs (depending on runtime) and working to smooth them over. I believe it helps everyone grow in their knowledge and expertise of the web over bespoke third-party abstractions.
(Shameless plug: Remix adapters polyfill these divergences with the goal to one day be no longer necessary.)