The V8 team's number one priority is Google Chrome. They don't really care much about supporting node, io.js, or any of the other projects that use V8.
As such, APIs break/change often from release to release which makes it hard to keep up. This is made worse by the fact that old versions are completely unsupported.
This isn't really the V8 team's fault - this is just what they are paid to do. And to be fair, V8 is frequently used outside of Chrome because it's the best JS engine around.
In practice, Mozilla's Spidermonkey and WebKit's JavaScriptCore offer comparable performance to V8, and they tend to have less breaking changes.
But V8 is definitely the engine that has the best marketing. Chrome 1.0 launched with that great comic by the legendary Scott McCloud [1], where several pages were spent on explaining JS engine performance -- something that most people had never thought about before... Ever since then, it seems like many assume V8 remains unique regardless of what's happened in the real world.
I agree -- I think you would be hard pressed to find substantial differences if you ran on top of SM, for instance. It was more than just marketing at the time, though. JSAPI (Spidermonkey's API) was C based and had a lot of pre-processor macro cruft at the time V8 came around and from the embedder point of view V8 was nicer to work with. Probably the biggest practical difference was that V8 exists in a separate repository. Spidermonkey must be pulled out of mozilla-central, and requires files in directories outside of js/src to build. Since Node (and other projects) embed V8 in their repos, it is more work to rip out Spidermonkey and keep it up to date. (source: I work with Spidermonkey a lot :))
JXcore is fork of Node that supports either V8 or SpiderMonkey. I suspect neither the Node or io.js developers are interested because they don't want the extra maintenance costs of supporting more platforms and abstraction layers. However, decoupling your product's core from its third-party dependencies is usually a good idea. V8 API and ABI changes have been enough a problem that someone created the NaN library (Native Abstractions for Node.js) to help Node plugin maintainers.
The third-runner JavaScriptCore has always been pretty good about embedding, though. (Apple has offered it as a separate framework with a stable API since 2004 or something.)
It seems to me that the reason why Chrome went with the in-house V8 rather than just improving JavaScriptCore wasn't so much technical as political. Ultimately they ended up forking the entire WebKit too.
Mozilla was bitten twice by its poor embedding support: Gecko vs WebKit and SpiderMonkey vs V8. The Servo team has learned this lesson and is making its embedding API a high priority.
This really makes me glad I'm not betting any of my critical projects on node js. To be told that certain things can't happen because some other party has broken/stopped maintaining the most critical piece of back-end infrastructure in the entire stack...wow.
Honestly, this is akin to betting all your marbles on Microsoft not breaking or forever maintaining VB6. Kind of insane to me.
Comments
The V8 team's number one priority is Google Chrome. They don't really care much about supporting node, io.js, or any of the other projects that use V8.
As such, APIs break/change often from release to release which makes it hard to keep up. This is made worse by the fact that old versions are completely unsupported.
This isn't really the V8 team's fault - this is just what they are paid to do. And to be fair, V8 is frequently used outside of Chrome because it's the best JS engine around.
In practice, Mozilla's Spidermonkey and WebKit's JavaScriptCore offer comparable performance to V8, and they tend to have less breaking changes.
But V8 is definitely the engine that has the best marketing. Chrome 1.0 launched with that great comic by the legendary Scott McCloud [1], where several pages were spent on explaining JS engine performance -- something that most people had never thought about before... Ever since then, it seems like many assume V8 remains unique regardless of what's happened in the real world.
[1] http://www.google.com/googlebooks/chrome/
I agree -- I think you would be hard pressed to find substantial differences if you ran on top of SM, for instance. It was more than just marketing at the time, though. JSAPI (Spidermonkey's API) was C based and had a lot of pre-processor macro cruft at the time V8 came around and from the embedder point of view V8 was nicer to work with. Probably the biggest practical difference was that V8 exists in a separate repository. Spidermonkey must be pulled out of mozilla-central, and requires files in directories outside of js/src to build. Since Node (and other projects) embed V8 in their repos, it is more work to rip out Spidermonkey and keep it up to date. (source: I work with Spidermonkey a lot :))
JXcore is fork of Node that supports either V8 or SpiderMonkey. I suspect neither the Node or io.js developers are interested because they don't want the extra maintenance costs of supporting more platforms and abstraction layers. However, decoupling your product's core from its third-party dependencies is usually a good idea. V8 API and ABI changes have been enough a problem that someone created the NaN library (Native Abstractions for Node.js) to help Node plugin maintainers.
https://github.com/jxcore/jxcore
https://github.com/rvagg/nan
Thanks for the info!
The third-runner JavaScriptCore has always been pretty good about embedding, though. (Apple has offered it as a separate framework with a stable API since 2004 or something.)
It seems to me that the reason why Chrome went with the in-house V8 rather than just improving JavaScriptCore wasn't so much technical as political. Ultimately they ended up forking the entire WebKit too.
Mozilla was bitten twice by its poor embedding support: Gecko vs WebKit and SpiderMonkey vs V8. The Servo team has learned this lesson and is making its embedding API a high priority.
This really makes me glad I'm not betting any of my critical projects on node js. To be told that certain things can't happen because some other party has broken/stopped maintaining the most critical piece of back-end infrastructure in the entire stack...wow.
Honestly, this is akin to betting all your marbles on Microsoft not breaking or forever maintaining VB6. Kind of insane to me.