Just like all statistics, these should be taken with a grain of salt, but I think Github's "pulse" breakdowns between Iojs and Node are pretty sobering.
Iojs: 49 authors have pushed 168 commits to master and 572 commits to all branches. On master, 8,474 files have changed and there have been 1,524,012 additions and 708,276 deletions.
Node: 30 authors have pushed 5 commits to master and 95 commits to all branches. On master, 10 files have changed and there have been 294 additions and 36 deletions.
It reminds me of Internet Explorer. Once it got "good enough", development slowed to a trickle until someone finally got fed up with it and started a new browser with a very rapid release cycle that continues today.
Node.js 0.10.0 was released on March 11, 2013. 0.12.0 was released almost 2 years later on Feb 6, 2015. By all accounts 0.12 isn't even a major change over 0.10.
The io.js team has done more in a few months than Joyent did in 2 years.
I, personally, don't care if node.js and io.js ever merge. One is clearly a superior product with a superior open source governance model.
> The io.js team has done more in a few months than Joyent did in 2 years.
This seems a bit one-sided. What Joyent has been doing is called "maintaining production software." That's something I've been missing in the web world lately. It's surprisingly hard to find high quality libraries that don't change all the time (that is, break all the time). Libraries like jQuery, normalize.css, and Lodash are the exception here. They're some of the few libraries that I'm comfortable guessing will look pretty much the same they do now a year from now.
That is not to say that I don't want to write my gulpfiles in ES6 as much as everybody else, but you have to understand that this whole forking thing scares off people who are looking for a platform they can invest significant time and money into (that is, write more than a million lines of code for).
Which breaking changes are there in io.js? I'm just curious, not been following it closely; but AngularJS 2.0 is a completely different API. You can't "migrate" an Angular 1 project to Angular 2, you need to rewrite it. That's understandably scary and horrible for some people.
For the most part, almost all JavaScript code and modules will run the same under io.js as node.js. The primary point of breakage is binary modules. io.js is constantly upgrading their V8 bindings, so binary modules need to be updated much more frequently than with node.js.
> Iojs: 49 authors have pushed 168 commits to master and 572 commits to all branches. On master, 8,474 files have changed and there have been 1,524,012 additions and 708,276 deletions.
With that much change in such a short time, it would be extremely optimistic to think something didnt break. If I had a lot of production code depending on node, those numbers would scare the crap out of me.
You can absolutely migrate angular 1 to angular 2. Following good practices (i.e not having 4k line controllers) that were place since its inception only makes that migration easier.
Server code is much easier to test with unit and integration tests than UI code which is part of the reason that people dislike breaking changes in UI frameworks more than in other kinds of libraries.
Did I read the number wrong, or is that an absurd amount of changes (note: I haven't look at the commit myself, as I have no idea how to get all the stats from github interface)?
That's about 800000 additional lines of code for 49 developers in a months, or ~16000 LOC for each developer. Unless additions and deletions are counted on a different unit, can anyone knowledgeable explain to me how the numbers are reasonable at all?
Joyent used to have the license on the top of virtually EVERY file in the repo for node. Someone removed all but one (6430 deletions) https://github.com/iojs/io.js/pull/311/files
I remember this was a common thing in free/open source projects some time ago[0].
At some point people started to believe that this was not necessary.
I am not sure of the legal implications, of either choice, just wanted to point out that the joyent people probably were not crazy :)
In every Berne Convention signatory country (which is pretty much any country that will matter to most people), published works are required by the convention to be copyrighted by default, whether or not there is a copyright notice, and the lack of a license means you have to assume you have none unless something else tells you differently. That basically makes embedding the license text pointless.
It certainly was common, though, which is/was probably because the US did not join until 1989, and prior to that US copyright law required a mandatory copyright notice, so a lot of people will have at least worked on projects old enough for this policy to have mattered.
Really? I've been putting the license in every file in my project because it's JavaScript and people drive by a website, see "foo.js" and have no idea where it came from or what license it's under. With the license in the file it's immediately clear.
Usually you'd concatenate and minify deployed JavaScript anyway. Sometimes you get a license in that, sometimes you don't. I don't think that many people really copy that much JavaScript from live sites these days...
> That basically makes embedding the license text pointless.
Embedding the license makes sense because otherwise others have to assume they don't have the right to use. The copyright notice on the other hand is pointless.
"The copyright and license notice is already in the LICENSE file. There is no justifiable reason to also require that it be included in every file, since the individual files are not individually distributed except as part of the entire package."
Unless you ask it, git considers file moves to be a complete deletion of the file along with the addition of the file. A good way to tell git to detect renames is to use the similarity flags: `git diff -M60% --shortstat` will consider files 60% similar to be renames.
We have been using node.js in production since almost the very beginning.
We have since switched to io.js and I would seriously hesitate to use node.js, due to the seismic gap release pattern, which is actually more likely to create issues. Node.js is definitely not "more stable" as Joyent like to claim.
io.js has almost all of the core developers from the original node.js, which is now basically just a ghost town.
For stability, critical fixes and core developer support go with io.js.
Not to mention, that breaking your services apart (to some extent) becomes pretty easy to test, and with something like docker/lxc it becomes trivial to test/configure a new service with updates for deployment in isolation from the rest of the system... and tested independently.
Why wouldn't node.js have more contributions? It's the official product and backed by a neutral company (Joyent).
Just like Sun does to Java, Microsoft does to C#, Google does to Golang. It's beneficial.
Joyent is a company of merit that stays out of politics. Integrity trumps popularity, sure it it can ruffle feathers time to time. Why not just enjoy the support and let things coast?
Edit: If anyone has proof otherwise, I'd like to see it. Name one time Joyent ever made a mistake in their open source stewardship.
Is this sarcasm? io.js would not exist if joyent hadn't made significant mistakes, e.g. failing to ship a new release for years, also this political point scoring alienated a lot of people - https://www.joyent.com/blog/the-power-of-a-pronoun
I use node.js daily, I've never had a problem. Nor have I heard any.
Failing to ship a new release, how is that Joyent's fault? It's core developers who are to blame.
I don't understand the point of the link you sent me. How would a gender neutral alienate people? The person they were talking about here wasn't an employee.
But why would Joyent consider rejecting a PR for gender pronouns as a fireable offense? Probably a website defacement / practical joke.
Edit: FYI - I don't follow this. I don't understand why a fork even exists.
Failing to ship a new release, how is that Joyent's fault? It's core developers who are to blame.
You really are out of the loop. The core developers were frustrated at Joyent not pushing their code, so they jumped ship. Joyent was the steward of the codebase, and they were at fault for not incorporating the developers' work.
How would a gender neutral alienate people?
It's the manner in which they handled the issue that was alienating. Screaming about how tolerant they are, all while screwing over one of their primary contributors, demonising him, and saying he'd be fired rather than retrained. They were soapboxing for cheap political points rather than actually being tolerant and understanding. It's why I actually laughed out loud when you described Joyent as a company that doesn't get involved in politics.
The irony is that the developer in question isn't a native speaker of English, and his native tongue is a gendered language, which likely contributed to his blase attitude on the matter. A little understanding, tolerance, and mature discussion and correction (instead of soapboxing) would have gone a long way.
> But why would Joyent consider rejecting a PR for gender pronouns as a fireable offense? Probably a website defacement / practical joke.
That wasn't a rejection because of gender pronouns. That was a rejection because one pronoun was changed from the docs, instead of all of them. This leads to:
- minor change, not suitable for a PR
- inconsistency, either change all of them to match, or leave them alone
> But why would Joyent consider rejecting a PR for gender pronouns as a fireable offense?
Because community pressure, basically. When there's an angry mob outside about to burn your company down, do you just give them who they want or let your company burn and have everyone else fired too?
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.
"process.nextTick() performance has been improved by between 2-42% across the benchmark suite, notable because this is heavily used across core (Brian White)"
Congrats to the io.js team! I know there's lots going on in the node vs. io.js world/debate/comparison/everything, but regardless it's so great to see a team working on an OSS project so well.
Ryan Dahl in 2011 interview:
"Hopefully in the next 6 months we'll release a 1.0 version of Node. The idea is to constrain what goes into "core" and not allow it to grow too big - so there will not be endless stream of feature additions. 1.0 will look pretty much like Node does now"
http://bostinno.streetwise.co/2011/01/31/node-js-interview-4...
Confusing name. I just spent a while trying to figure out what this thing is. It should be hereafter forbidden to name anything ".js" unless it actually is a library written IN JavaScript and designed to be used within JavaScript code.
The first time I read this sentence, I thought it was some kind of I/O library for users of Node. I thought "npm-compatible platform" meant "this is some kind of library that can be installed/added to your project by using npm".
Exactly. I was too afraid to ask actually and be downvoted and labeled totally uncool. So what is it? I'm still not smarter after reading the FAQ. A "Javascript Platform". Aha. What do I use it for and what problem does it solve for me?
I see it's a fork of Node.js. So people use Node.js to write server programs in Javascript, I heard. So is io.js then "competing" with Node.js then?
I was at a conference recently and had the privilege of mikeal (@mikeal) explain the differences between io.js and node.js, as well as the future that he and the io.js team saw for node as a whole.
All that he articulated at the conference is pretty much what you see on iojs.org. What struck me in particular was how reasonable and level-headed he was about the entire controversy. While it would be very easy to castigate Joyent for their incompetence, mikeal was positive throughout the whole presentation, without having that positivity detract from the mission of io.js (i.e. he said things that were nice, but not empty or hollow.)
His fellow, emilyrose (also on github), also seemed like a fairly intelligent person.
From that short encounter alone, I would say IO.JS appears have quite to have a healthy community. Here's hoping they can take Node off of Joyent's hands, and merge IO.JS into it.
Been using it production for a couple months now, no issues. We have a reasonable number of IO.js powered microservices, we've seen anecdotally better performance for some use cases but regressions in none, however we've seen SIGNIFICANTLY cleaner code (ES6 yay!) and a much simplified build (no transpilation to ES5!).
Was nervous at first, but now I see no reason to use code Node again.
I think it's still entirely possible for Node's new org to pretty much adopt iojs's technical committee nearly as-is. There's still no version conflicts. There's a minor support niggle for some internationalization bits in node 0.12's core, but beyond that, there's still a chance.
My only thought is that when io.js/node reaches a point for an LTS release, that they do a major bump for the LTS, and another for the ongoing dev... so that #.x.x is LTS. instead of ~#.#.x
Personally I would wait but you can certainly use io.js as you do node. I commented elsewhere in this thread about my whys so I won't be annoying and repeat them here but if you want to experiment or need some bleeding edge performance in some of the areas that io.js is faster (the newer V8 isn't faster in all situations) go for it otherwise I'd stick with node for now.
You are not forced to update (in another environment, I have customers with Rails apps in production of version 2.3, 3.0, 3.2, 4.0, 4.2) but you have the option to develop with the latest technology. In those Rails examples: I'll start new projects with Rails 4.2 and Ruby 2.2.2 and not with what I had two years ago. In the JS world, I'd start with ES6 and the latest v8, not the old one from node.
I know I'm coming to this a little late, but I'd be really interested in knowing what the Node creators think is happening with node currently. The current top comment here[0] cites an active community with iojs, and a not so active community with node . However, I can't imagine that the node creators would say that node is stagnant or perfect, so before we start comparing node to IE, has anyone done any kind of reconciliation with the node devs?
I understand why iojs forked, but I really hate to see communities get abandoned or go stagnant like this.
As far as I understand, the majority of Node core contributors thought it necessary to move Node.js to io.js, and are now active there. io.js is basically the new Node.js, barring the name. It's less a fork, and more a rename, to get control back from Joyent who could have threatened some of the core team over the trademark.
Well .org is pretty much the standard TLD for open source projects. While it would be "cool" to use .io it might confuse some people.
It's very common for example that projects have an .org for their Open Source software and .com or other for their business behind it (see wordpress.org vs wordpress.com)
Ya, makes sense. What about all the trendy open source stuff that have the TLD .io as their suffix like socket.io etc? How did the .io trend start anyway?
Iojs: 49 authors have pushed 168 commits to master and 572 commits to all branches. On master, 8,474 files have changed and there have been 1,524,012 additions and 708,276 deletions.
Node: 30 authors have pushed 5 commits to master and 95 commits to all branches. On master, 10 files have changed and there have been 294 additions and 36 deletions.
That's for the last month.