Echo JS 0.11.0

I think in an ideal world both exist, with node.js being a more stable lts release cycle and io.js being a more continuous release cycle.  I think there's room for both release styles.

Isn't the problem they will at some point have some real or even perceived incompatibility. At this point all library writers will have to test on and customise for both projects. People are lazy so they won't do this. Then network effects take over and the bigger project wins.

Maybe I'm over simplifying. But I think that it's very hard for two very similar but slightly incompatible projects to prosper. See jenkins vs. hudson.

The reasons to fork from a release standpoint provides a variant that is appealing for certain types of development. The numbers that it appeals will dictate, at least partially, its success/popularity.

The same applies from a maintenance perspective with the semver approach.

There's room for both or N forks really, as long as the users don't get burned out on too many options, which was the topic of a recent JavaScript MVC framework article (can't find it now).

http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/

Interesting question. I think forking is a good way to demonstrate what (and how) things can improve so everyone who likes to test/use it, can use and try it. If the concept seems to be very popular, its good parts can be ported to Node. For Node to tumble over, a new project has to be revolutoniary and really beneficial in order to kick Node of its throne.

As a Senior CS Engineer I appreciate a solid, common and stable ground. Maybe I am too old already on my forties. 

Recently I have moved to frontend running away from enterprise burocracy but I swear I had never imagined seeing that much fragmentation and dispersed tooling in the last year since I decided to move from C# to Javascript/Angular/Django. Everything feels wrong in the current state of affairs.

This is worst than no man's land and I am talking web only, I am not including mobile (web/hybrid/native), tablets, wereables and the list goes on... Besides this, it seems like everybody has gone mad and is happy to publish half baked components before having breakfast.

Thanks for helping clearing things out in the node arena kids! Hope you are having fun in the process... I am sure I would do the same if I was on my twenties/thirties. Kudos!

Everyone seems to be exaggerating the likelihood of incompatibility, as far as I'm aware io.js is simply supposed to be a bleeding-edge version of node. There is no need for community library authors to test on or support io.js, because in theory io.js should be fully backwards-compatible with node.js other than the incredibly unlikely circumstance that io.js adopts a version of V8 which deprecates features used in node's version of V8 or changes it's API in a non-backwards compatible way, which would be no different from the incompatibilities you'd encounter by using a version of node to run an app written for an older version of node.

Forking node allows people to use new/experimental V8 features/improvements while still tapping in to the already massive node ecosystem and alleviates those users from having to compile their own node/V8 binaries. This way those working on personal/dev status projects can use the latest io.js to have the new features they might want, and those working on public/production projects can use the latest node.js without having to worry about instabilities.

To me node.js or io.js is analogous to choosing between an LTS/stable release or bleeding-edge/unstable release release of your OS. There's no universally correct choice, it depends on your specific requirements. Having both projects doesn't fragment the community, for example most Linux distro packages are compatible with both stable/unstable releases of the OS, the only exceptions being different versioned dependencies which is generally resolved automatically by your package manager anyway.

Or is io.js the Rocket of the node.js community?  The downside of this is fragmentation.  Rocket and Docker are already firing warning shots.  Granted, Rocket seems to be in response to all of the commercial backing the Docker is getting but I don't think commercial backing is a bad thing and can be positive.  What we don't need is two implementations that are copies of each other because the people in the two camps can't get along.  They could all be contributing to one and innovating twice as fast.  I don't know if this will happen with io.js or not.  I'm still not sure what they are trying to prove.

I'm concerned that this creates fragmentation when the community would be better served working together.  As Node and IO diverge eventually they become incompatible module maintainers have to support both, or possibly they choose just one or the other; either way both of these are a loss for the community since one takes up valuable time supporting two platforms and the other option leaves us with a less healthy module eco-system for each platform.

Compare this with the Ruby community.  MRI is the reference implementation and more people than not continue to use it.  Rubinius and JRuby try to achieve performance gains through various means, but the attempt there is not to diverge from MRI, but rather to stay in lock step.  Even there, where the intention is not to diverge, there end up being some incompatibilities.  Now JRuby 9000 is falling even further behind MRI (https://github.com/jruby/jruby/wiki/Roadmap).  The end result is that more often than not people just choose MRI.

I think especially right now as Node.js is still an up and comer that this division could be toxic to the community as a whole.