Not sure if this is a joke, but assuming it's not - it's the standard now, and it's been out for... 2 whole months?!

It's based on node.js from just before the 0.12 stable release. The v8 and libuv base libraries and other pieces have been updated. It's not like they started io.js from scratch. It's that most of the core developers have moved on to io.js at this point.

Barring a merge back into node.js (which could still happen), I don't see myself going back for new projects.

That's a fine attitude, but nothing about it justifies talk of "standard".

For us JS bystanders who get whiplash from release announcements, I think it's pretty hilarious. I definitely read it as a joke.

What does the time it's "been out" has to do with anything?

For one, it's a fork, not a new product -- so it carries all the old development from node.

Second, it got all the best contributors from the node community.

So, while it might not be a standard yet in numbers, it's very well poised to be.

iojs is definitely not the "standard" by any means... It's accelerating at a quick pace, but I haven't heard of any major sites making the switch yet. Many native modules (node-gyp compiled) aren't functioning yet, and the streams module was a bit finicky as of a couple weeks back. I'm looking forward to the market competition actually. Can't go wrong with having two standards battle to be the best.

Modules are quickly switching to using nan, which is required anyway for working with both 0.10 and 0.12, so io.js merely accelerated the incentive to use it.

As far as "big sites", several are starting to roll out io.js deployments. Most places don't blog about every upgrade to every internal piece of infrastructure. If you're doing the SOA thing properly, you can start rolling out io.js for new services without removing the versions of node used for other stuff.

At npm, we have some io.js, lots of node 0.10, erlang, java, spidermonkey, python, redis, postgres, etc. It's pretty common to use different stuff side by side in little servers that talk to one another. Less dramatic to talk about than pretending your'e gonna make some big switch-over though.

Yep, io.js v1.1 works really fine and i switched too.

My experience has been that just about every module that uses native code (there are more than you think) doesn't work in IO.js because of the changes to the V8 apis. So until all of those are updated to work with both I'll have to stick to Node.

That is being tracked here:

https://github.com/iojs/io.js/issues/456#issuecomment-730639...

As a native module owner, I made mine work right away and it was work that I needed to do anyway for Node compatibility because changes in v0.11.13/15 broke me as well.

I've had the opposite experience. I've only had a couple modules that use native code that haven't worked, and most of those monkeyed directly with V8 so I wasn't terribly surprised they didn't work with the upgraded version.

Example? I'm curious because mostly everything has worked for me.

I'm using:

io.js v1.1.0

npm v2.4.1

node-gyp v1.0.2

Ursa

fibers

I just crudely tested this pull request. Seems to work. https://github.com/laverdet/node-fibers/pull/205/files

Right the fix was submitted a few days ago. I couldn't get meteor to work on iojs

I am neither side of this fight , Can you explain what is this V8 api story ? seems this is root of all fight in *.js community

3.24.x represents a significant departure from previous v8 APIs. Specifically, the v8 team moved from what I would term, 2nd Generation VM Primitives to 3rd Generation VM Primitives, including 2nd Gen Isolates, GC changes, UTF8/ASCII changes, and other siginificant API changes, in December 2013). Details can be found here [0] in the v8 team's "Design Doc Tracker". Up until late 0.11.x series, nodejs was based on v8 3.14.x, whose last commit by the v8 team was in May 2013, nearly two years ago. Needless to say, there were many changes/optimizations it was lacking. And even if they were to base nodejs on the latest 3.28.x (3.28.73), its last commit was August 2014, 6 months old. It seems odd to me, that they made the effort to get to 3.28.x but didn't go past 3.29.x because of the i18n changes v8 introduced. It's really easy to exclude that stuff if you don't want to deal with it. Bonehead move in my opinion.

[0] https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7...

I am just curious, what happens when people start writing ES6 io.js modules and posting them to NPM? Won't it be an issue for older versions of node? Is NPM going to start fragmenting because of this?

The npm registry is already used for a bunch of stuff that it wasn't really intended for (e.g. front-end UI components, coffeescript, etc.). One solution for projects that need older versions of node would be to transpile es6 dependencies using https://github.com/esnext/es6-module-transpiler for example.

Sure, but no worse (or even all that different) from any other Node release. The community will gradually upgrade, and it'll be fine.

You don't see many people using `node.http.cat()` any more, for example. And yet the community survived ;)