5 ms·

Node.js current uses an unmaintained version of v8. io.js v8 is more up to date and they seem to have a better relationship with Google v8 team. If you look at

by iends 12y ago

Node.js current uses an unmaintained version of v8. io.js v8 is more up to date and they seem to have a better relationship with Google v8 team. If you look at the git history of the two projects, the Node.js project contributions have slowed down drastically, while many of the active developers have been contributing to io.js instead. This means more stability in terms of bug fixes and also more features

weego 12y ago
Is there any obvious reason why they are so behind on v8 versions? It feels like that would be pretty much in the top 2 things you need to do as a maintenance part of being in "control" of node.
- hendzen 12y ago
  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.
  - pavlov 12y ago
    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/ http://www.google.com/googlebooks/chrome/
    - apaprocki 12y ago
      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 :))
      - cpeterso 12y ago
        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/jxcore/jxcore https://github.com/rvagg/nan https://github.com/rvagg/nan
      - pavlov 12y ago
        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.
    - cpeterso 12y ago
      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.
  - PopsiclePete 12y ago
    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.
malandrew 12y ago
This graph says it all: https://camo.githubusercontent.com/4e8294e5bf159efd81ba19d4432f3c7a41e711da/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f4342576147593955554141705276522e6a70673a6c61726765 https://camo.githubusercontent.com/4e8294e5bf159efd81ba19d44...

by iends 12y ago

weego 12y ago

Is there any obvious reason why they are so behind on v8 versions? It feels like that would be pretty much in the top 2 things you need to do as a maintenance part of being in "control" of node.

hendzen 12y ago
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.
- pavlov 12y ago
  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/ http://www.google.com/googlebooks/chrome/
  - apaprocki 12y ago
    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 :))
    - cpeterso 12y ago
      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/jxcore/jxcore https://github.com/rvagg/nan https://github.com/rvagg/nan
    - pavlov 12y ago
      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.
  - cpeterso 12y ago
    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.
- PopsiclePete 12y ago
  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.

malandrew 12y ago

This graph says it all: https://camo.githubusercontent.com/4e8294e5bf159efd81ba19d4432f3c7a41e711da/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f4342576147593955554141705276522e6a70673a6c61726765 https://camo.githubusercontent.com/4e8294e5bf159efd81ba19d44...