Now we just need io.js to merge with node. I feel like I can't use io.js for anything beyond experimentation until the inevitable happens.
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.
> I still think node and io.js using the same package manager is simply untenable
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.
> 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.
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.
> Creating a different repository for modules that use language improvements seems like a bad idea to me.
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.
I'm mostly concerned with using APIs that are only available in io.js. Doing so means I can't share my modules in any reliable way since io.js and node both use npm and I certainly wouldn't create multiple versions of my modules. This leaves me developing using only node APIs at which point io.js is nice for experimentation but I'm not sure about doing serious work for it until it's strictly an application (no module sharing, etc).
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).
That's a valid point. Perhaps package.json should support a property that defines which version of node/io.js are supported in the module.
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.
This exists but now you're limiting your audience to use APIs and syntax in a slightly newer, different version of node (io.js). I'm not convinced that's worth it in my opinion. I'm not sure npm can support using the same package name deployed under different engines (it doesn't appear to as far as I can tell) but that's annoying to maintain.
Anything ES6y implemented in modern versions of V8 that aren't in the version that Node.js is using cannot be used. E.g., if you use `"strict mode";`, `const` works in an ES6 way in io.js but throws a syntax error in Node, though if you don't use `"strict mode";` you continue to get the pre-ES6 non-standard `const` that V8 has provided for a long time.
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.
But that would create yet another problem. npm has a lot of infrastructure setup so now you have to duplicate all of this infrastructure, get people to adopt your new package manager that's identical to the old one (except has slightly different module support) and move the community to it (or get them to use it in parallel).
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.
I can't speak for anyone else... but since shortly after the first iojs release, I've been targeting it for all new development. Deploys are moving towards docker based deployment so can, in theory support anything that can be tested on its' own for integration tests.
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.
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.