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!
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.
...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?
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.
Current Project Team Members
============================
Isaac Z. Schlueter
Ben Noordhuis
Bert Belder
Fedor Indutny
Trevor Norris
Chris Dickinson
Colin Ihrig
Mikeal Rogers
Rod Vagg
> 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.
For the record, I believe that's what should be written as the first answer on the FAQ (and maybe on the site's index.hml). The current one is atrocious.
Its not strange, most of the people involved are core members of both projects. Its the same project, really. Its just that iojs actually has new releases, and node doesn't anymore.
Yes I know, I need to add `s/anymore/yet`. But the statement is pretty much accurate. Its been almost 2 years since 0.11.0 was released and 0.12 is nowhere in sight.
Are node/io permanently joined to V8? I know that Oracle has been putting some effort into getting Avatar.js to be fully compatible with node and run on the JVM, but it isn't gaining much traction.
With 1098 commits to libuv, which represents 35.2% of all commits to that project and the most number of commits from any single individual, and 1409 commits to node (13.8%, 3rd after Ryan Dahl and Isaac Schlueter), I'd say that him "getting thrown under the bus" is a huge understatement of what happened.
I don't think he got "thrown under the bus" - he moved to a position were others did not want to defend him or even just keep on. Unsurprisingly, I would add, he should know the other people.
Still, the inclusion shows that not all bridges are burned, which makes me happy.
I don't see truth in your statement that core people did not want to defend him. Shitstorm happened mostly by outsiders/ignorants. He didn't want to continue in such a climate. Joyent wrote a blog post that ruined their reputation. - Good net effect one year later is that node might free themself from Joyent and become much more open/inclusive.
Could someone make (or provide a link to) a summary of the melodrama for outsiders ? It being not too partisan for one side or the other would be a plus.
I was interested myself, so I did a little google-foo.
So Ben Noorddhuis was a major contributor to NodeJS and a volunteer (that is, not a Joyent employee). It turns out Ben rejected a pull request that would have made pronoun in the document gender neutral. The documents were already grammatically correct, but whoever made the pull request had a political preference for using a non masculine pronoun. Ben rightly saw this a trivial change. But the political harpies made an issue of it. Joyent put an embarrassing and immature blog posting which essentially called Ben an "Asshole" and said that if he was an employee he'd be fired.
https://www.joyent.com/blog/the-power-of-a-pronoun
Ben, on the other hand, handled himself quite well.
https://github.com/joyent/libuv/pull/1015#issuecomment-29568...https://news.ycombinator.com/item?id=6845286
Because everyone who doesn't live in one of the SJW/progressivist cult bastions realizes that:
a) Talk is cheap, action matters, and the PC police's main strategy is to complain until other people change, instead of enacting change themselves. Accommodating them is useless, they will simply find something new to complain about. Apologies are always insufficient, defiance is considered a declaration of war.
b) Language is indeed important, and redefining concepts like "privilege", "misogyny" and "harassment" to mean whatever the club of the perpetually offended thinks they mean is damaging to sane discourse.
Even though he stopped being part of core, he has remained active in Node.js development. It's part of his job at StrongLoop I suppose. A fresh start with an open governance model at least should mean that most politics are set aside.
Except "identity politics" aka inclusiveness are at the heart of their open governance model... Or did you miss the drama over their code of conduct; that they were going to one and how they solicited and followed advice from noted social justice advocates in drafting it.
It confuses me deeply that this fact could turn people off of the project regardless of its other practical and technical merits.
I hope so. Pretty much everyone on that list except isaac and mikeal are apolitical.
Mikeal is overtly political. Isaac is political from time to time since he's strongly aligned with the identity politics mob that attacked ben noordhuis back in the day. I really hope identity politics doesn't creep into the io.js governance.
A great way to stop identity politics becoming an issue is to bring it up unprompted through a throwaway account on Hacker News. Anonymously singling out specific members of the community that you dislike and labeling them as bad actors is particularly helpful.
The fact that opinions like these are still a thing says more about the opinion than his commitment to the node/io/libuv community.
edit: obvious commit statistics below/above.
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.
That website needs serious work in terms of wording. Absolutely zero information on the website apart from the extremely vague tagline. I clicked a few links and all I could find was politics. Without the context given on HN I would still be wondering:
Is it a node.js replacement? Is it a NPM replacement? Is it a dog? Is it a cat? Can I eat it?
Even you want to sell something to people (even if that something is free as in beer) they need to know what that something is, first.
completely agree. I didn't even get it was a node replacement. A spork of node? What is that? I might be missing some tech vocabulary, or just some native-english understanding. But the wording could be much more clear.
The merge between the current 0.10.35 branch and the 0.12 branch is almost done (https://github.com/joyent/node/milestones/0.11.15), we can expect version 0.11.15 within then next few days. 0.11.15 will be a release candidate for 0.12.
On the other hand, they've been saying that 0.12 will come out 'soon' for over a year, so this too may take longer than I expect.
As someone who's been waiting for that '0.12 soon' for over a year, io.js releasing as announced is amazing (even more-so is their open communication).
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.
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?
"io.js is an api-compatible alternative to the node.js runtime, including support for the npm ecosystem, that aims to release faster than the node.js release cycle and move according to a community-driven open governance model."
Given the tremendous volume of packages released to npm, the current one-liner initially just doesn't convey much information. In context of the comments here, it all parses perfectly, but I was one of many who needed this context to understand the (apparent) goals of the project.
The huge collection of modules on npm is one of the strongest factors node.js has going for it, so it makes sense for them to emphasize that they're not breaking compatibility with this in forking node.
They don't provide the Javascript runtime - Google does that. This is a fork of Node.js - glossing over this is at least a little disrespectful to Node.js.
There was a trademark issue between them and Joyent that also made the node-forward GH repo to go private. They might not be comfortable using term Node.JS on the frontpage.
> The main point seems to be that it's run on an open governance model
Ya, I think the main problem is that no one has any idea what that means from a practical sense. Will my code go faster? Will I get better support? etc.
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.
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');
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.
I'm liberated on the server in my own app, but not necessarily if I'm publishing something for everyone to use. In that case I'm either forced to feature-detect my way along, or target certain engines. The reason I think the latter will happen is devs to whom node was an escape-hatch from client-side hell will loathe the idea of going back. E.g. [1]
> 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.
Though I'd imagine this will not hold true with addons, seeing as there are vastly different versions of the V8 engine.
I'm not sure it's worth publishing both ES6 and ES5 transpiled versions when you could just glue the transpiler into Node's "require": http://6to5.org/docs/setup/#require-hook
Please don't rely on require hooks in libraries. They are kind of evil in applications already (because they amplify the "synchronous require" problem). Test your library against a version of 6to5, compile, publish, and remove that paragraph in font size 48 from your README.*
(*) I hope you add such a paragraph when your library relies on a global require hook that changes the default behavior of require for all .js files in all libraries.
With a lot of files app startup can be delayed and the event loop be blocked. Which messes with timeouts among other things. The problem is that each file is loaded from disk and parsed in series without any level of parallelism (no real way around that in a pre-ES6 world). With CoffeeScript you put the time it takes to compile to JavaScript on top of that. If you have a big app with a lot of CoffeeScript files, it might be worth trying to compile them ahead-of-time instead. Though your mileage may vary in how much it changes.
As I said: there's no guarantee it affects you. But messing with timeouts during startup (where stuff might be failing and prevent server processes from recovering correctly) can be an issue. Even when the process is long-running in general. If that issue affects your particular program is a different question.
will it impede functionality? probably not.
will it add precious time to server process start time? definitely, especially if the problem gets compounded.
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.
It looks like iojs is only going to ship features once they've shipped in Chrome without a flag. The compelling reason to use the features is that they're useful!
EDIT: I don't think anyone is going to be sympathetic to holding back from using conveniences because people are choosing to stick with an old runtime. It's a different ballgame than the browser.
I would make a strong cut between "application code" and "library code". For the former compilation to ES5 is overkill because the author of the code controls the runtime. For the latter the library either has to contain a long list of "tested with the following versions of the following runtimes and with the following versions of the following ES6-to-ES5-compilers" or it should be compiled pre-publish into a format with known semantics.
Example: I wanted to use the WHATWG streams code. But then I realized that they used an ES6 subset that is currently only compatible with traceur. The result: I had the choice between patching the code or downloading traceur, compiling the library, somehow get traceur out of it, and then require the resulting file into my otherwise fully working ES6 environment. I take a nice, tested, ES5 version any day over that experience.
If the audience of your library is literally just one version of iojs and nothing else - then yes. But that seems pretty restrictive. Especially since we just reached the point where reusing libraries in different contexts (browser/node) became viable. I really hope we won't throw that away.
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?
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.
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.
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?
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.
It was not my post and I care less about being downvoted and more about the problem that some people seems to prefer downvoting to explainating.
Downvoting, -in my opinion, is for things like redditism, clear breach of site guidelines etc. It is not for being uninformed (within reasonable limits) and certianly not for asking reasonable questions.
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.
> When a corporation sinks their hooks into an active open source project, it's only a matter of time.
An ironic statement given that one of the main motivations for io.js is to upgrade to the new awesome versions of V8 with all of its great new features.
V8, of course, has always been "corped": it was created and is maintained almost entirely by Google.
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.
> The official name is io.js, which should never be capitalized, especially not at the start of a sentence, unless it is being displayed in a location that is customarily all-caps (such as the title of man pages.)
Not really, at least according to semver (which is what iojs uses). Stability of the API is denoted by a 1.x.x, it isn't necessarily an indication of the quality of the implementation, beta or otherwise.
Node 0.12 was always being referred to as 'pretty much the 1.0 API', not calling it 1.x.x was a kind of 'get out of jail free' card in my opinion. So i'm glad the iojs team have least drawn a line in the sand and declared their API stable.
1.x is not really about stability either. To quote from the semver FAQ:
>How do I know when to release 1.0.0?
>If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
To me it just follows on the ridiculousness of the Node community in general. A tool at version 0.10 and everyone screams about how stable it is and can't wait to bet their business on it.
A bunch of people are unhappy and fork the project, and make the initial version 1.0, but make a point of saying (despite not using a related version number/identifier) that it's beta.
Realistically it sounds like both projects should be at v0.9.x.
This seems like a step away from "ridiculous" to me.
Declaring something as 1.0 means that any 1.X releases are going to be backwards-compatible with the 1.0 spec.
This is objectively different than versioning something 0.X, which implies that the baseline spec is not finalized.
Calling something "Beta", however, just means that a feature-complete major version is still being actively developed (i.e. new minor features and bugfixes).
In other words "1.0 Beta" just means "Stable spec, active codebase".
The 1.0.0 release was called 1.0.0 - there has been a patch release since. Pretty much any software I can think of lists the latest release on the homepage rather than linking to a static version, but you're right it's a little confusing that specifying a version in the querystring doesn't actually appear to link directly to that version.
EDIT: confusing if the intention of the iojs team was to have the querystring actually mean something... they may well not have that intention, in which case meh :)
My point wasn't about the patch version it's about the software being called "beta" while the version doesn't reflect that at all.
If the api is fixed and its just bug fixes before release why isn't this 1.0.0-beta or -rcN, with a 1.0.0 (a vanilla version is always considered higher than one with an identifier like "-beta" or "-rc1"
Sure, but that's more of a reflection on the convention (some might say 'rationality' ;) of associating a single vector of 'production status' with a number beginning with 1. Again, this is a semver thing, not an iojs thing.
Yes, I've watched some of the io.js minutes on YouTube and they basically reached a consensus that this was definitely necessary. They want to be a drop in replacement for Node.js.
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.
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).
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
"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."
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.
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.
Some npm modules require specific version of node. If iojs overwrites `node` you may see node-gyp use algernative fallback build, which causes installation failure. At least now, the better way is to keep symlink to node as node. Use iojs when needed.
It takes over the `node` name via symlinks. But you can have a working REPL side by side by overwriting with the prior node one again. Node isn't uninstalled.
This is cool and I am excited. I have been playing with Node for a while but the pace towards stable was so glacial I couldn't take the software seriously.
First of all they're not the same thing. Coffeescript transpiles to JS (ES3 or 4 if I remember well) and ES6 is a new standard (not finished yet). Maybe one day coffee may compile to ES6 (but that's not likely since that would break support with older browsers). As said before, ES6 may reduce the need of transpiled languages but won't replace them. From my point of view, ES6 will never replace ClojureScript nor TypeScript (ES6 doesn't bring the power of a LISP like clojure or the type system of TS). As for coffee, many people may still prefer its more lightweight syntax that ES6 does not intend to replace either.
Let's say that ES6 will provide a better runtime that may make transpiled languages less useful. Yes, ES6 does arrow functions and classes but it also provides many more cool stuff that the transpiled languages may never support such as generators if they intend to keep backward compat to older browsers. If you are in this case you should bet on ES6. If you don't care and are happy with what's included in coffee, use coffee ! You can always compile it to JS and continue your project with ES6 !
To sum up, transpiled languages are not dead and are still way more flexible than vanilla JS (as they don't depend on a big specification such as the ES specs) but ES6 does improve the runtime, and one day transpiled languages may use this new runtime.
Heroku node maintainer here. No official docs yet (it's like an hour old already! :) but it works about the way you might guess: use engines.iojs instead of engines.node in your package.json.
We're also excited to see node hit a 1.0 and merge in new V8, ES6 features, etc. I'm especially excited about Cluster's round-robin load balancing which has been a compelling reason to use 'unstable 0.11' for a while.
EDIT: To clarify, though I haven't tried it myself, it looks like you can just specify `"engine.iojs": "1.0.0"` in your package.json, and Heroku will install the entire io.js system for you.
As I understand it, the io.js devs think Node.js should have switched to 1.x ("stable") a long time ago. But from their perspective, this is io.js's first release with their own build infrastructure and they made a lot of aggressive changes (updated V8 dependency, etc.), so they're calling their own release beta-quality. Makes sense?
It doesn't make sense to release beta quality software as "v1.0.0" without any reference to being a beta in the version itself. Either use a 0.x version or use a -beta -identifier if the api is fixed but stability is not guaranteed
The "(Beta stability)" is just text on that webpage. The version is just 1.0.1.
By any sane logic any release after 1.x should be considered stable UNLESS otherwise stated.
This is why we have the concepts of things like "dev", "alpha", "beta", "rc" (release candidate) identifiers for versions.
Nowhere does io.js use any of these terms except in that homepage. So now, anyone relying on any other source to get the product either as source or in a binary package has no way to know if it's considered "stable" yet.
So what I want - basic common fucking sense is what I want. Nobody in their right mind would release software marked as version "1.0.0" with full knowledge and even the barest of acknowledgement, that it's only beta quality.
The explanation I've seen so far is that the people behind the fork are sick of NodeJS never reaching 1.0 despite being used in production. Sure thats a good reason to make it 1.0 - because a heap of cool kids have jumped on the bandwagon and bet their business on it, it must be stable right?
Oh wait, but then they admit that it's only beta quality. So they want it to be versioned as if it's appropriate to use it in production, but they know its actually not.
> "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."
The windows install for this took the liberty of removing my original nodejs install, removed the binary and batch files from the program files\nodejs directory, even though I opted to install iojs to its own folder. Nodejs shortcuts are removed from start menu, and path variables were removed as well.
Go to reinstall nodejs, and that install says a later version is already installed and cancels the install without giving me an option to install anyway.
Node.js uses MINOR even = stable, odd = unstable (which is not semver) and is still in 0.x even though it's been used by giants in production all over the world for a couple years.
Honest question, do you have good luck with semantic versioning? I find it's pretty hit or miss on whether an X.Y.2 patch breaks functionality in the previous X.Y.1 build.
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!