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.
Comments
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.