I always wondered why Node.js is based on V8 in the first place; to my (limited) experience, SpiderMonkey's API is both simpler in use and better documented. Was it a speed thing in Node's early days?
Cool move, nevertheless. Sounds like a pain to maintain, though.
> I always wondered why Node.js is based on V8 in the first place
Probably just a case of that engine being the one he was playing with at the time (or had some/more experience with) so it was the one his experiment that became node.js got implemented in.
A lot of implementation decisions get made this waym, especially with projects that start out as an experiment or a proof of concept for a thought experiment: if the list of reasons why not to use the tool you currently have in your hand are insignificant at the time, why mess around looking for other tools to try as well?
Sometimes this means a project gets tied to a particular tool even though another tool might offer some useful features, which is the case with the current node.js implementation. In the grand scheme of things it may not matter: is node.js suffering (or likely to suffer in future) because it is tied V8? Would making node.js flexible about its JS engine add enough overhead that it is undesirable? It is certainly worth experimenting with other JS engines though, so they have answers to those questions (maybe is isn't worth it, but now that is known for sure, and maybe it is worth it and the benefits of a change (or generalisation) can be demonstrated with real examples).
> Dahl originally set out to build Node atop Mozilla's SpiderMonkey – the JavaScript engine included with Firefox browser – but this effort didn't last long. After about two days, he switched to Google's V8. "V8 is just a nice, clean library," Dahl told us earlier this year. "It's compact and extracted away from Chrome. It's distributed as its own package, and it's easy to build and it's got a nice header file with nice documentation. It's kind of constrained. It doesn't have dependencies on other things. It seemed much more modern than the Mozilla stuff."
I mostly agree about the clean API. It's compartmentalized and makes more sense to me overall. Documentation though...
As for maintenance, I'm really hoping it won't be too bad. Once V8Monkey is standing, it shouldn't be terrible to keep up. And so long as Node doesn't start using new or modified APIs, then SpiderNode should be fine.
SpiderMonkey used to be very slow. Wikipedia says Node.js was released in 2010, I'm not sure when development started, but if it was when V8 was significantly faster, it seems like an obvious choice.
Cool move, nevertheless. Sounds like a pain to maintain, though.