The Web Can't Afford a JavaScript Runtime Monoculture
9 points by hongminhee
9 points by hongminhee
I think this argument makes way more sense on the client (browser) side, not server side. Is the “web” broadly speaking defined by the set of JS runtimes we can deploy on the backend? Maybe I’m biased since JS is one of the last languages I want to use server side, if at all.
The issues of standards control client side seems far more relevant considering the general users of applications. (Nearly) nobody switches which web application they are using based on whatever developers decide to do server side, so long as it continues to work according to their (relatively basic) criteria.
So yeah, competition is good, but I personally am not convinced consolidation of JS runtimes for server development matters nearly as much as the browser.
yeah you kinda said what i was thinking, i read
Every major server runtime borrows its engine from a browser.
And I'm just like....... C# ASP.net doesn't borrow an engine from a browser. Ruby on Rails doesn't borrow an engine from a browser. Python doesn't. I do all my stuff in D, which is completely separate.
Maybe every major javascript server runtime does, but javascipt is a fraction of the world of "major server runtimes".
To be fair, I'm certain that's what the author means. But, the point still stands that the world of server runtimes in general is vast.
That was my reaction to the headline. I agree, and the article didn't really convince me. It is sad about Deno, but I'm personally much more worried about Mozilla finding an independent revenue stream.
Apple built Safari on an open-source engine called WebKit
Nope, WebKit is Apple's fork that underlies Safari. The origin was KHTML.
Have Deno/Bun ever gained enough traction for Node not to be considered a monoculture?
Was the author concerned when we had just node.js for over a decade?
The web will be fine, competition wise we’re still in a better position now than we were 10 years ago. It’s never been easier to build an alternative if people want it, long term funding is another discussion.
Good thing there is no such mono-culture. There is Mozilla's spidermonkey, which Firefox, Gnome and Servo use. There is QuickJS-ng, etc. IIRC there is JS implementation for the JVM that has some use cases for Clojure devs, etc. Using a different run-time doesn't mean that you'll be able to use all the libraries from npm though
Here’s what I’m worried about: the monoculture that took over browsers is now consolidating the server.
It’s not a monoculture when there are three major JS implementations in browsers.
Every major server runtime borrows its engine from a browser. Node, Deno and Cloudflare’s runtime all run on Google’s V8, the engine inside Chrome. Bun runs on Apple’s JavaScriptCore, the engine inside Safari. This is bad.
That’s because browser are where the JS VM innovation happens. It’s like Dillinger robbing banks because “that’s where the money is.”
A web standard traditionally needs two independent implementations before it counts as a standard
Yes, and I count two different JS VMs in your previous sentence.
Moreover there’s a very good third one: SpiderMonkey. As far as I know, nobody is using it server-side at the moment, but I guess it shouldn’t be too complicated to do.
Many GNOME-ecosystem desktop applications run on SpiderMonkey (also Cinnamon-ecosystem apps by shared lineage). That's not servers, but it is something other than a browser!
It is used server side in a couple of things, or at least I know there are forks of it being used like that.