Hacker News Reader

Comment by consto | Hacker News Reader

Don't forget that JavaScript also has multiple fairly popular implementations.

Ehhhhhhhh kind of. Wake me up when node (or something like it) runs on SpiderMonkey, or Electron runs on JavaScriptCore, or you can pick Chakra on Lambda. The whole point is "there's a major version most people use, and sometimes there are competing versions that are significantly different that significantly fewer people use". That's definitely the case w/ JavaScript.

You have been able to run ChakraCore on Node for a bit now, with potentially more engines to follow. That can presumably later also have ramifications later for Electron and Lambda, both of which are built around Node.

Hey I don't disagree that options exist. But I think Chakra on Node is extremely niche and almost no one uses it (despite being possible for over 2 years now). My entire thesis is that multiple equivalent equally (more or less) popular implementations is primarily (maybe only) a C/C++ thing. There are niche languages where this is the case, but they're very niche. There are also very niche implementations of popular languages or platforms, but no one uses them.

We extol the virtues of multiple implementations because it makes the ecosystem healthier, but is that even really true? Is Python's ecosystem unhealthy because theres no full alternative to CPython? Is Java's? Is serverside JS?

I generally think we haven't thought through the implications of the virtues of multiple implementations -- mostly I think the opportunity costs are bananas. Platforms that at all approach C/C++'s progress on this issue have longstanding standards committees and corporate-backed engineering teams. It's simply infeasible and a hugely bad decision to build multiple implementations if you don't have that, which, it turns out, almost no language devs do.

Hmm, I guess you have a point there. That said, as a primarily-frontend-web-developer, multiple implementations of Javascript definitely is a thing, and I would never optimise solely for V8. (Although unfortunately (but it is unfortunate!), I see that as a trend that is starting to appear more and more. But I guess that's the point of the post as well.)

It is on the Server. But V8, SpiderMonkey, JavaScriptCore, and Chakra are all running the same code on the web, and most people target all four.

OP spends a whole paragraph describing the effort Mozilla expends to ensure devs are able to target at least Firefox in addition to Chrome:

> We have a Tech Evangelism bugzilla component for outreach to sites who use techniques that don’t translate across browsers. When new sites appear that deliberately block Firefox (whether because the launch team took the time to test with Firefox and determine the user experience wouldn’t be acceptable, or because cross-browser compatibility was an explicit non-goal), Firefox engineers go find the performance cliffs and fix them. Mozilla has a long-history of promoting the benefits of multiple implementations of the web platform; some of the old guard might remember “Works best in all browsers” campaigns and the like. If you squint properly, you can even see this promotion in the manifesto (principles 2, 5, 6, 7, and 9, by my reckoning).

I think it ends up that sites happen to mostly work in most JS engines because most sites don't do a lot of difficult stuff, and if they do they're using libraries that work pretty hard on cross-browser compatibility. I definitely don't think significant effort is spent targeting Chakra, for example. I think most FEs would laugh at the mere mention. Most I know push back against even considering Firefox compatibility.

Reply on news.ycombinator.com