Edit: Damn that was quickly downvoted. It seems the HN community is more behind io.js than it was a few months ago. I still think node and io.js using the same package manager is simply untenable so I'm just waiting for something to give before I decide to use io.js beyond experimentation.
There are a whole bunch of packages in npm that are targeted at environments other than node (e.g. the browser).
For me the big difference is not between node/io.js for which a simple setting in your packages.json would be enough to sort out, but rather between es6 style modules and node style modules. I'd probably rather have a separate repository for es6 style modules.
Setting the engine will separate things but this also means your package is now only available for that engine. npm doesn't give you a way to submit the same module multiple times to target different engines. So setting this limits the amount of environments your module. Maybe that's okay but the great thing about node + npm has been the ability to install and use any module you find; separating things would mean you'll come across modules you need and you might not be able to use. This kills the experience in my opinion.
> I'd probably rather have a separate repository for es6 style modules.
Why would you want one repository for ECMAScript 5 modules and one for ECMAScript 6? The end goal is to move everything towards ECMAScript 6 so would you want this to merge back into regular npm after a certain amount of time? Creating a different repository for modules that use language improvements seems like a bad idea to me. It's a good way to segregate modules from one another.
It's not just the language improvements in general, I'm thinking of the es6 module spec in particular. I've experimented with es6 modules that 6to5 post install or things like that, but the way es6 modules interact with npm is a bit kludgy at the moment. I'd like something that made es6 modules feel native, natural and the default.
I like io.js, but I'd much prefer to see a merger (even if it's a 10/90 to io.js favour). Only the name node itself is pretty ingrained, I think everyone would be best served by a merger.
Sort of like the merb/rails merger. Both sides made the harder, more mature decision to join forces even though they both probably had to give up some personal preferences. But I'm sure none of them would regret it now.
Really the biggest sticking point for me is using npm between the two. Node not supporting ES6 is also an issue as you can't write your code using ES6 unless you want to only support io.js or you want to transpile (ugh).
This probably already exists in node world regarding binary dependencies. I use at least one that's only compatible with 0.10 but there's no way to know that until you get a build error on 0.12.
A minor one is that in io.js, `require('events') === require('events').EventEmitter` while that's not true in Node (where require('events') just gives an object with `EventEmitter` and possibly other properties on i.
I don't think a community of two platforms that are 97% similar with over 145,000 packages can thrive with a fork. Do all 145,000 modules move to the newly forked npm? Do they even have a choice?
I love the ideas behind io.js I just don't understand how it can survive on its own unless it can somehow kill node. I can't see both coexisting for long.
The bigger thing is that security and critical updates are hitting iojs quickly and following semver, they are not hitting node in a timely manner.