top | item 8884128

Io.js 1.0.0

634 points| elisee | 11 years ago |iojs.org | reply

186 comments

order
[+] duncanawoods|11 years ago|reply
In their words, io.js is "A spork of Node.js with an open governance model".

Hmm. Lets hope the spork gets spooned so that no projects get knifed. If not then I guess we have to hope for a knork so we don't get stuck with a couple of chopsticks.

Glossary

Forking : Creating a fork to intentionally diverge from main-line development.

Spooning : Merging a fork back into the main line of a project

Sporking : Creating a fork that you would really like to become the next main-line version but you kinda have to prove its awesome first (sporks are pretty awesome)

Knifing : Action killing a project, abandon hope :(

Knorking : A fork replaces the original project which dies off i.e. a fork knifes the original

Chopsticking : Two forks vie for popularity splitting the community and becoming lone chopsticks. Chopsticks need to work together to make stuff happen!

[+] qooleot|11 years ago|reply
Lets hope they keep momentum, otherwise they'll be 'corkscrewing' the community!
[+] Fishrock123|11 years ago|reply
For posterity to anyone who still reads this, the spork thing is mostly my fault. And it sort of caught on.

I do website and irc stuff for io.js and I had trouble describing what the project was in relation to node.js.

So I called it a spork, because "sporks are friendlier". Whatever that means. Aside from being friendly.

Proof is somewhere in the io.js irc logs back near when the project sporked.

http://logs.libuv.org/io.js

[+] benihana|11 years ago|reply
groan

Don't get me wrong, thanks for the information. But seriously. It's like when you come up with a whimsical naming scheme for your home network devices and you get trapped in that naming scheme and have to come up with more and more obscure Lithuanian folk demons that fit into your conventions and it becomes a parody of itself and you're not sure if you're serious or joking anymore.

[+] quaunaut|11 years ago|reply
...Okay, normally I roll my eyes at people asking "What does this do" but Christ this is ridiculous.

From the FAQ:

> What is io.js?

> io.js is a JavaScript platform that is compatable with Node.js & npm.

What does that even mean?

Edit: Thanks for those answering. I started figuring out what it was, but sometimes folks really need to learn that "A correct definition" is not the same as "a useful definition". However, if it's as cool as described, definitely might give it a shot.

Edit2: Is this expected to be as stable as Node.js consistently? And how solid is the upgrade path- is it going to be a pain upgrading between versions the way Node used to be, or is there a smoother upgrade process? I guess what I'm wondering is, do I get any benefit from using this right now, or would it be smart to still wait for whatever version they consider release quality?

[+] mintplant|11 years ago|reply
It's a fork of node.js with ES6 support. The goal is a faster release cycle and an updated V8 engine, plus an "open governance model" as opposed to Joyent's domination of node.js prime.

https://github.com/iojs/io.js

    Current Project Team Members
    ============================

    Isaac Z. Schlueter
    Ben Noordhuis
    Bert Belder
    Fedor Indutny
    Trevor Norris
    Chris Dickinson
    Colin Ihrig
    Mikeal Rogers
    Rod Vagg
[+] elisee|11 years ago|reply
io.js is a fork/continuation of Node.js "unstable" 0.11.x branch. Node.js stable, under Joyent's stewardship, has been stuck in 0.10.x land for over a year.

io.js has many of the top core Node.js contributors. They're trying to move server-side JavaScript forward with open governance, faster release cycles, ES6, etc.

[+] davesque|11 years ago|reply
Agree...couldn't find a clear explanation anywhere within several clicks of the home page. If it's a fork of node.js with ES6 support, as people are saying, they should put that on the front page or at the top of the FAQ section or on the front page of the documentation.
[+] Killswitch|11 years ago|reply
In a gist, io.js is node.js with faster release cycles using more up-to-date versions of V8 along with an open governance
[+] fergie|11 years ago|reply
io.js is a program that makes JavaScript run on a server.

io.js is a fork of node.js but is "better" because:

1) io.js always uses the latest JavaScript engine.

2) io.js is not controlled by private interests.

[+] monkey_slap|11 years ago|reply
I still cannot figure out what this actually is besides Javascript
[+] elisee|11 years ago|reply
(Huge) changelog from the latest stable Node version v0.10.35, including all changes from unstable v0.11: https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md

Also of interest, the state of ES6 in io.js: https://github.com/seegno/io.js/wiki/The-state-of-ES6-on-io..... Highlights: 'let', generators, promises, template literals, symbols are all enabled by default. EDIT: just realized this wiki page has been updated and integrated into the website at https://iojs.org/es6.html

[+] aasarava|11 years ago|reply
Tip to anyone rolling out a library and wanting others to start using it: It'd be helpful if the home page or the FAQ explained what io.js actually does and why a developer might want to explore it further. "Bringing ES6" is only helpful if you know what ES6 is and have already decided it's something you need. Likewise, the FAQ simply says io.js is compatible with Node.js and npm, but that doesn't give you much to work with. Can someone who knows the project explain the benefits?
[+] tach4n|11 years ago|reply
You're right that the page linked in OP needs improvement. The phrase to focus on is this:

> io.js is an npm compatible platform originally based on node.js

It's not a library, it's a platform that's based on node.js. It's more or less a fork of node or "spork" as they call it.

The github repo is a bit more clear: https://github.com/iojs/io.js

The main point seems to be that it's run on an open governance model: https://github.com/iojs/io.js/blob/v1.x/GOVERNANCE.md

[+] Killswitch|11 years ago|reply
Basically anything you can do in Node.js you can do in Io.js. It's nothing that really breaks backwards compatibility. The benefits of Io.js over Node.js is that it'll have a faster release cycle bringing in newer versions of V8 JavaScript Engine, allowing you to use newer features of that in your code.

In Node.js to use ES6 you would have to use the --harmony flag to enable them because the version of V8 that is used is so old. Whereas in Io.js anything V8 deems stable is available in Io.js without having to use the --harmony flag.

[+] _greim_|11 years ago|reply
I suspect there will be a split in the npm ecosystem now, not so much along node/iojs lines but along es5/es6 lines. There's already been lots of discussion about whether module builders should publish es6 code, or should everything be transpiled down to es5 code in order to keep the ecosystem unified (the unspoken caveat being, around es5).

I think es5 is a dinosaur as of today, so I say go ahead and publish es6 code, and if you want to be nice to es5 people then add a prepublish transpiler that makes something like this possible:

    // es6 people can do
    var foo = require('foo');

    // es5 people can do
    var foo = require('foo/es5');
[+] wycats|11 years ago|reply
Important to note: because JavaScript itself is always backwards-compatible (1JS), any code that runs on Node will run on iojs, but not necessarily vice versa.

That means there need not be a split in the ecosystem: people who want maximal coverage can target ES5, while people who want the latest features can target ES6. Unlike the browser, however, where people can't control their runtimes, I suspect there will be much less tolerance for sticking with older versions of JavaScript.

Indeed, the pain and suffering people have felt with IE6 will likely make everyone much more willing to reject an unnecessary lowest-common-denominator approach on the server. We're liberated on the server. Let's act like it.

[+] jkrems|11 years ago|reply
> es5 is a dinosaur as of today

I don't think so. People publishing libraries in ES6 are asking for trouble. There are far too many half-complete ES6 implementations out there and compiling to ES5 definitely is the way to go (for libraries) unless there's a really compelling reason not to.

[+] bshimmin|11 years ago|reply
I don't think you can really call something "a dinosaur" when the standard that is supposed to supersede it hasn't even formally been published yet!
[+] namuol|11 years ago|reply
I think a better option might be to use some kind of flag in `package.json` -- kinda like the `engines` flag.
[+] untog|11 years ago|reply
As someone who tries as hard as they can to avoid project politics and the like: is this the new Node.js? By which I mean I know it isn't the Node project, but where is most of the mindshare these days? Is io.js a small offshoot or has it taken most of the Node devs with it? Or is it the same code just with a more aggressive release schedule?

Also, when do we go back to one executable already?

[+] shadowmint|11 years ago|reply
If we're lucky this will turn into the 'unstable branch' with new features and things which is periodically folded back into the 'stable' node.js platform.

...but if node wont play ball, it'll become 'the new node', yes.

(there's a lot of backstory to this, which you can read about here: http://blog.izs.me/post/104685388058/io-js)

[+] james33|11 years ago|reply
I think it is probably too soon to answer that question since this is the first release available for devs to start playing around with.
[+] maga|11 years ago|reply
Since there are features in Io that are neither in the current version nor planned for the future versions of Node, I guess Io.js should be explicitly specified as an engine in the package.json file of Io-specific modules. Tracking those modules will be a good metric of how well Io is received by the community.
[+] gobengo|11 years ago|reply

  $> diff <(node --v8-options | grep harmony) <(./iojs --v8-options | grep harmony)
  1,6c1,18
  <   --harmony_typeof (enable harmony semantics for typeof)
  <   --harmony_scoping (enable harmony block scoping)
  <   --harmony_modules (enable harmony modules (implies block scoping))
  <   --harmony_proxies (enable harmony proxies)
  <   --harmony_collections (enable harmony collections (sets, maps, and weak maps))
  <   --harmony (enable all harmony features (except typeof))
  ---
  >   --es_staging (enable all completed harmony features)
  >   --harmony (enable all completed harmony features)
  >   --harmony_shipping (enable all shipped harmony fetaures)
  >   --harmony_modules (enable "harmony modules (implies block scoping)" (in progress))
  >   --harmony_arrays (enable "harmony array methods" (in progress))
  >   --harmony_array_includes (enable "harmony Array.prototype.includes" (in progress))
  >   --harmony_regexps (enable "harmony regular expression extensions" (in progress))
  >   --harmony_arrow_functions (enable "harmony arrow functions" (in progress))
  >   --harmony_proxies (enable "harmony proxies" (in progress))
  >   --harmony_sloppy (enable "harmony features in sloppy mode" (in progress))
  >   --harmony_unicode (enable "harmony unicode escapes" (in progress))
  >   --harmony_tostring (enable "harmony toString")
  >   --harmony_numeric_literals (enable "harmony numeric literals")
  >   --harmony_strings (enable "harmony string methods")
  >   --harmony_scoping (enable "harmony block scoping")
  >   --harmony_classes (enable "harmony classes (implies block scoping & object literal extension)")
  >   --harmony_object_literals (enable "harmony object literal extensions")
  >   --harmony_templates (enable "harmony template literals")
[+] bsimpson|11 years ago|reply
I understand that Node was lagging behind on merging newer versions of V8, but holy hell: how did they have so many patches to the standard library that weren't properly released?
[+] dsissitka|11 years ago|reply
Version 1.0.0 (Beta stability)

The hell? Seems it's intentional:

https://github.com/iojs/io.js/issues/251#issuecomment-694177...

[+] ChiperSoft|11 years ago|reply
They're sticking the strict semver with no tags, and explicitly wanted to abandon the 0.x version numbers, so the TC decided to do 1.0.0 as the first release but make it clear that it's not production ready.
[+] k__|11 years ago|reply
Doesn't 1.0.0 simply mean, API stability?
[+] _urga|11 years ago|reply
Congratulations to the team who made this possible. Thanks for your hard work. Looking forward to switching binaries.
[+] drderidder|11 years ago|reply
Node got forked because it got corped. When a corporation sinks their hooks into an active open source project, it's only a matter of time. Mysql, Maria, Hudson, Jenkins... same story. io.js is the way forward, and congrats to the core team.
[+] silverwind|11 years ago|reply
OP: sorry to nitpick, but the proper capitalization is 'io.js'.
[+] elisee|11 years ago|reply
HN auto-capitalizes the first letter when submitting, sadly. EDIT: Turns out it doesn't do it a second time if I edit, so, fixed :) EDIT2: Aaaand it reverted itself to Io.js, somehow.
[+] ulisesrmzroche|11 years ago|reply
Actually, it's both io.js or Io.js. The one that got canned was IO.js.
[+] sambeau|11 years ago|reply
Am I alone in being bemused and amused by this:

  Version 1.0.1 (Beta stability)
Surely the main point of a 1.0 release is "stability" and to no longer be "beta"?
[+] nickfargo|11 years ago|reply

  ls -l /usr/local/bin/node
  lrwxr-xr-x  1 502  staff  4 Jan 13 20:10 /usr/local/bin/node -> iojs
Is this necessary?
[+] ykl|11 years ago|reply
What is a spork, as contrasted with a development fork?
[+] elisee|11 years ago|reply
It's a playful way to say they don't really want to fork the Node.js ecosystem. io.js will evolve alongside Node.js and the core team is open to merging back with Node.js if possible.
[+] Gys|11 years ago|reply
I think it is the same ? Some people think a spork sounds less offensive (more friendly) then a fork ? Also as a utensil (which these are both).
[+] thomasfoster96|11 years ago|reply
From what I can understand, io.js is now node with the latest version of v8 and ES6(+ES7) features enabled by default (as opposed to behind a flag).

I'm wondering, what technical reasons are there for Node not using the latest version of v8 for each release? I can understand Node keeping some new ES6/7 features behind a flag (just as some are behind a flag in Chrome).

[+] ivank|11 years ago|reply
V8 updates bring incompatible changes to the V8 API, and many node extensions written in C++ need to be updated. Hence the decision to stick with an old V8, even though it's no longer maintained by Google.

There is a compatibility layer to assist with making these modules work across different V8 versions: https://github.com/rvagg/nan

[+] chadpaulson|11 years ago|reply
Congratulations to the io.js team! I look forward to future releases. Specifically, no longer having to use --harmony_arrow_functions.
[+] acdanger|11 years ago|reply
"This package will install io.js v1.0.0 and npm v2.1.18 into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node."

Why the symlinking as node?

[+] Killswitch|11 years ago|reply
Because Io.js is a Node.js replacement, but most of the time you're probably going to instinctively type `node script.js` and not `iojs script.js` so the symlink is just a helper.
[+] adregan|11 years ago|reply
Homebrew asked me to overwrite my node symlink with the iojs symlink. I decided to link iojs to iojs on my own. I hope I'm not spinning myself into some technical debt here, but for now, I'd like to maintain both.