6 ms·

Meh, too late. io.js is the standard now.

by antouank 12y ago

prottmann 12y ago
Yep, io.js v1.1 works really fine and i switched too.
- Touche 12y ago
  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.
  - AnkhMorporkian 12y ago
    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.
  - jekrb 12y ago
    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
    - pmalynin 12y ago
      fibers
      - jekrb 12y ago
        I just crudely tested this pull request. Seems to work. https://github.com/laverdet/node-fibers/pull/205/files https://github.com/laverdet/node-fibers/pull/205/files
        pmalynin 12y ago
        Right the fix was submitted a few days ago. I couldn't get meteor to work on iojs
    - mattkrea 12y ago
      Ursa
  - apaprocki 12y ago
    That is being tracked here: https://github.com/iojs/io.js/issues/456#issuecomment-73063920 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.
  - 0xFFC 12y ago
    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
    - oso2k 12y ago
      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_7uAri7Njtig7fKaPDfotU6huOa1alds/edit https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7...
bshimmin 12y ago
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?!
- tracker1 12y ago
  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.
  - hyperpape 12y ago
    That's a fine attitude, but nothing about it justifies talk of "standard".
- dikaiosune 12y ago
  For us JS bystanders who get whiplash from release announcements, I think it's pretty hilarious. I definitely read it as a joke.
- coldtea 12y ago
  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.
ZoneGhost 12y ago
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.
- IsaacSchlueter 12y ago
  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.
skeeterbug 12y ago
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?
- olalonde 12y ago
  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 https://github.com/esnext/es6-module-transpiler for example.
- IsaacSchlueter 12y ago
  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 ;)

Meh, too late. io.js is the standard now.

prottmann 12y ago

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

Touche 12y ago
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.
- AnkhMorporkian 12y ago
  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.
- jekrb 12y ago
  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
  - pmalynin 12y ago
    fibers
    - jekrb 12y ago
      I just crudely tested this pull request. Seems to work. https://github.com/laverdet/node-fibers/pull/205/files https://github.com/laverdet/node-fibers/pull/205/files
      - pmalynin 12y ago
        Right the fix was submitted a few days ago. I couldn't get meteor to work on iojs
  - mattkrea 12y ago
    Ursa
- apaprocki 12y ago
  That is being tracked here: https://github.com/iojs/io.js/issues/456#issuecomment-73063920 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.
- 0xFFC 12y ago
  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
  - oso2k 12y ago
    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_7uAri7Njtig7fKaPDfotU6huOa1alds/edit https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7...

bshimmin 12y ago

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?!

tracker1 12y ago
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.
- hyperpape 12y ago
  That's a fine attitude, but nothing about it justifies talk of "standard".
dikaiosune 12y ago
For us JS bystanders who get whiplash from release announcements, I think it's pretty hilarious. I definitely read it as a joke.
coldtea 12y ago
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.

ZoneGhost 12y ago

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.

IsaacSchlueter 12y ago
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.

skeeterbug 12y ago

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?

olalonde 12y ago
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 https://github.com/esnext/es6-module-transpiler for example.
IsaacSchlueter 12y ago
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 ;)