Dave Mandelin has a nice post responding to the Google V8 team’s new Crankshaft additions to their JavaScript engine. Good reading, but all pretty much what you would expect in the currently highly competitive world of JavaScript implementations. What really caught my attention was a comment by RH Ryan that, in part, said:
Call me naive, but why can’t you guys all get together and work on 1 common ECMAScript engine. It seems like a huge waste of human intelligence for there to be 3 major open-source Javascript VMs. The Chrome Team have gone ahead and said “OK Fair Enough, we don’t actually want to re-invent the wheel with another DOM renderer, let’s use WebKit”. It won’t affect Firefox’s popularity in the slightest, and you can spend time working on making either V8 faster, or making Firefox itself better!
I admire your work and am not trying to diminish its impact. It would take time but I think both projects (and Safari if they were amenable to the idea) and their combined millions of users would benefit from getting your collective compiler/VM/JIT-expert heads together.
So, sorry Rusty, but I am going to have to call you naive. Competition is good. It’s what drives innovation whether you are talking about commercial or open source software development. Software monocultures stifle innovation, even when they are open source based.
Even with the best of intentions such a combination couldn’t innovate as fast as what we have been seeing going on with JavaScript implementations for the last few years. There are always competing technical approaches for solving hard problems like building a fast JavaScript engine. It seldom is clear which approach is best (if best even exists). But to actually ship software you have to make a choice and stick with it. Sometimes you make the wrong choice and just have to live with it for a while. Often you won’t even know if you made the wrong choice unless somebody demonstrates that an alternative would have been better. Multiple independent teams working on competing JavaScript engines allow technical alternatives to be experimented with in parallel. We all get to see which approaches work best and when the code is open source we can all benefit from the most successful efforts.
So no, we shouldn’t wish for a single universal JavaScript engine. Along the same vein, we should wish for more competition to Webkit as a core browser building block. The last thing we need is a browser monoculture.
Comments on this entry are closed.
For what it’s worth…
I believe you misunderstand or unintentionally misrepresent the commenter’s position.
I read that he strongly agrees that Firefox should continue to compete with Chrome. He strongly believes that competition begets differentiation and innovation. He, like you, is anti-monoculture.
He is arguing IMHO that, especially within the open source for public benefit sphere, that replication diminishes innovation and begets cascading waste, which is self-evident here.
If there are irreconcilable differences between the projects e.g. design philosophy, key metics, etc., then clearly communicate them to the commenter and the rest of us who believe we understand his position. Otherwise, perhaps accept that it is helpful advice to merge the projects.
I’m not sure I’ve helped anyone here, but there you have it. 🙂
RL
I suspect we are just going to have to disagree on this.
From what I’ve seen, putting multiple expert heads together does not necessarily increase innovation. Often it decreases it because of the pruning and compromises that must occur in order to move forward as a group.
Parallel efforts often do contain replication and unnecessary replication certainly should be avoided. But overall I don’t see the inherent replication in parallel projects as a source of “cascading waste”. Instead I see it as a fertilizer of innovation. I’m much more concerned about fostering innovation than I am about minimizing redundant work.
I agree. I made a comment over at http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/ back when Mozilla adopted the Nitro assembler from Apple (and then YARR too) as I was worried that this would reduce innovation.
Boris said “there will be just as many JS engines as before. In the short term, there will be three parts to the Mozilla JS engine: interpreter, method jit, trace jit. Long-term there will be at least method jit and trace jit; whether the interpreter sticks around is unknown. And yes, the part being used from Webkit is a very small part of the entire JS engine.”
I guess there needs to be a balance between not innovating at all, just bringing in pre-made parts from other people, and a NIH attitude, where everything is written from scratch regardless of the stability of various options.