Politics and "what it may mean for the future" talks aside, are there any API / performance / engineering differences between io and node today? I mean, there's a lot of talk regarding why joyent is bad or how joyent did nothing wrong, but from a js user's point of view, I'm rather more interested in the tangible non-human differences in node and io.
In short, speed of development and the open governance structure seem to be the two key advantages of io.js.
io.js is on a very fast release cycle using semver for versioning. The don't maintain the node.js concept of a "stable" and a "development" build (e.g., 0.10 and 0.11). Node.js developers want to use a "stable" release in production, and so were stuck on 0.10 for over two years.
io.js is integrating the latest v8 and libuv releases, giving developers access to new ES6 features (and enabling stable ES6 features by default). Node.js developers as stuck on an old V8 with poor ES6 support, requiring transpilers like babel.
io.js also now has significantly more core contributors than node.js. For what I understand, Joyent only had 1 dedicated node core developer for a long time.
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
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.
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.
As far as I know (I'm quite new in Node), io.js wants to join the ES6 pretty soon, and most of the developers have gone to io.js from Node.js. So, while there might not be a big enough difference right now, if they continue separated there will be soon enough.
No, io.js is a fork of joyent/node by many original core contributors. io.js has more es6 support since it's based on a newer version of v8.
Development on joyent/node slowed to a crawl and now the NodeFoundation is begging the io.js developers to return. If things remain separate, joyent/node will probably not progress much more and eventually everyone will view io.js as the "next" version of node.
Divergence is what we are worried about. I am hoping they come back together with the io implementation being the bleeding edge going back into node stable.
Not so sure about that being the best way. I agree that it would be the best for not confusing short-term. However, there are also many problems with that approach, mainly that Node.js is not of the community, it is from Joyent. While this works great in some cases (Linux), there were apparently many problems with Node.js.
I think the best would be:
1. Joyent giving the name to io.js so they can keep developing Node.js at a fast speed while keeping the name to avoid confusion.
2. As 1 is highly unlikely, IMO the best next thing is for io.js to gain market and popularity as fast as possible.
Comments
Politics and "what it may mean for the future" talks aside, are there any API / performance / engineering differences between io and node today? I mean, there's a lot of talk regarding why joyent is bad or how joyent did nothing wrong, but from a js user's point of view, I'm rather more interested in the tangible non-human differences in node and io.
In short, speed of development and the open governance structure seem to be the two key advantages of io.js.
io.js is on a very fast release cycle using semver for versioning. The don't maintain the node.js concept of a "stable" and a "development" build (e.g., 0.10 and 0.11). Node.js developers want to use a "stable" release in production, and so were stuck on 0.10 for over two years.
io.js is integrating the latest v8 and libuv releases, giving developers access to new ES6 features (and enabling stable ES6 features by default). Node.js developers as stuck on an old V8 with poor ES6 support, requiring transpilers like babel.
io.js also now has significantly more core contributors than node.js. For what I understand, Joyent only had 1 dedicated node core developer for a long time.
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
This graph says it all: https://camo.githubusercontent.com/4e8294e5bf159efd81ba19d44...
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.
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.
As far as I know (I'm quite new in Node), io.js wants to join the ES6 pretty soon, and most of the developers have gone to io.js from Node.js. So, while there might not be a big enough difference right now, if they continue separated there will be soon enough.
Huh?
No, io.js is a fork of joyent/node by many original core contributors. io.js has more es6 support since it's based on a newer version of v8.
Development on joyent/node slowed to a crawl and now the NodeFoundation is begging the io.js developers to return. If things remain separate, joyent/node will probably not progress much more and eventually everyone will view io.js as the "next" version of node.
Divergence is what we are worried about. I am hoping they come back together with the io implementation being the bleeding edge going back into node stable.
Not so sure about that being the best way. I agree that it would be the best for not confusing short-term. However, there are also many problems with that approach, mainly that Node.js is not of the community, it is from Joyent. While this works great in some cases (Linux), there were apparently many problems with Node.js.
I think the best would be:
1. Joyent giving the name to io.js so they can keep developing Node.js at a fast speed while keeping the name to avoid confusion.
2. As 1 is highly unlikely, IMO the best next thing is for io.js to gain market and popularity as fast as possible.
io.js isn't very bleeding edge though. That's just FUD.