Io.js and Node.js reconciliation proposal
github.com
github.com
However io.js seems to be setup the right way here. Javascript development growth is still in massive growth phase. It is hard to prove the singularity exists when paths keep diverting.
I think it is probably healthy to have 2+ or have one win out in the market. Or maybe create others as javascript becomes more prevalent. As the overall javascript development market gets bigger, this will happen more and more. If it gets crazy divergent then standards come about so they work together better. Everything is going to be alright.
And how does one not get caught in a dependency trap, where one of the modules you use ultimately (perhaps after upgrading) needs io.js, and another needs nodejs.
Recalling the GCC/EGCS schism in the late 1990s, I predict that Joyent will support Node 0.12 as an LTS release and io.js will become Node™ master.
http://www.softpanorama.org/People/Stallman/history_of_gcc_d...
No they aren't. If you look at the changes to the Technical Comittee. The proposal is to add 3 members to it. I can't help but think there are way more people at Joyent. The TC seems to have alot of power on the direction of the project.
It doesn't seem reasonable to effectively stage a coup on node and ask Joyent to give up control over it.
I must admit, I had some weird notion when I first started programming that the world of software geeks might be just a little bit less drama-centric than the rest of the human world, but I was very wrong. The soap-operatic emotions around Node are amazing to me. Good lord, it's JavaScript on the server, not royal palace intrigue...
There are completely logical technical reasons for forking node into io.js. There are even political changes which need to be made.
But instead of trying to reasonably discuss the future of Node in a collaborative fashion, io.js has essentially issued an ultimatum which determines the entire governance structure of Node (including an entirely new management team). It's a desired coup, driven by an ultimatum, in the guise of a "proposal."
They are not really starting a discussion, this is more of a "you need to do everything different, or else..", as if they are now building up some evidence that they can later use to support their argument of "hey, /we/ tried to be compatible, but it is /their/ fault".
But I'm probably reading too much into this.
My opinion? I shall say that, as far as we can see, looking at it by and large, taking one thing with another in terms of the average of the will of the working groups, then in the final analysis it is probably true to say, that at the end of the day, in general terms, you would probably find that, not to put too fine a point on it, there probably isn't an easy way to tell if they'll vote one way or the other. As far as one can see, at this stage.
I do see that there is a real dilemma here. In that, while it has been the policy to regard policy as a responsibility of Joyent and administration as a responsibility of Joyent's officials, the questions of administrative policy can cause confusion between the policy of administration and the administration of policy, especially when responsibility for the administration of the policy of administration conflicts, or overlaps with, responsibility for the policy of the administration of policy.
As it was already said they run the same package manager and claim compatibility. This means you either can't take advantage of any new API in io.js ever to allow your module to work in both or you take the road where you're transpiling to support one and the other. It's not sustainable and it's prone to issues.
That said, I'm not sure if Joyent will be receptive to such a move.
http://www.softpanorama.org/People/Stallman/history_of_gcc_d...
io.js can certainly benefit from these fixes but I don't think it'll be a "shitshow".
https://groups.google.com/forum/#!msg/v8-users/UUyavs0KtwE/d...
So this means that the branch is supported until Chrome 42 goes in to the stable channel. Though a case could be made that since 4.1.0.21 is tied to Chrome 41, which is still on the Beta channel, and "Our stability expectations are the same for every branch (once it starts shipping on Chrome stable, which is roughly 6 weeks after it's been created)"
[0] - https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md
[1] - https://chromium.googlesource.com/v8/v8.git/+/4.1.0.21
Open-source competition is critical and beautiful. This is a major function of Github and a big reason why it’s successful.
Forget what the industry needs. Technology creates the industry. Now we're at the crossroads between the next great tech and the next great bureaucracy. Which side sounds cooler?
Political debates occur when everyone involved agrees that they're at "A" and they want to get to "B", but they disagree on the best path to take. A technical debate is when there is a fundamental disagreement about whether "B" or "C" is the better end goal.
In the EGCS case, the goal of building a cross-platform compiler collection was clear, but the process of getting contributions accepted into the mainline had become increasingly onerous for a large number of (potential) contributors. With LLVM vs GCC, there's a fundamental difference of opinion regarding the importance of modularity of the compiler stack (LLVM) vs speed and efficiency of the generated code (GCC).
In the case of node.js vs io.js, it seems to me that everyone still agrees they want an Ecma standards-compliant, evented JS runtime built upon V8 and libuv. If io.js had forked, say, because they wanted to rebase on JSCore or Rhino, then I could see the value in keeping both projects around.
As it stands, if I am a developer, and I want to help build an Ecma standards-compliant, evented JS runtime built upon V8 and libuv...then where do I go? node.js? io.js? If that choice is made based on governance model, then we're enriching the world of governance models, not the world of tech.
Most importantly, we should not spend any more of our precious time on this unnecessary distinction.
Change is the only certainty. As a javascript developer I now have two options to help me through those changes. That makes me happy.
Lastly, I love a good fight.
It's a huge win already and will continue to be.
Check out the other top 5 issues - it's mainly a bunch of people talking to themselves.
Anyhow - I genuinely wanted to link to both - not trying to poke at node.
https://github.com/joyent/node/issues/9022 https://github.com/joyent/node/issues/8987 https://github.com/joyent/node/issues/8975 https://github.com/joyent/node/issues/8974 https://github.com/joyent/node/issues/8931
Just randomly went to the issues page and looked
http://readwrite.com/2015/02/03/joyent-nodejs-incubator-iojs...
Edit: Agreed with @caipre's reply that the quote isn't as bad as it sounds totally out of context (in hindsight I should have included more of the context in my reply too), and was probably meant tongue-in-cheek. However, I think considering the (perceived? real?) animosity between these two projects, his choice of wording could have been better.
One more thing: Developers using IO instead of Node are,
well, not invited.
“IO.js, what’s that?” asked Joyent CEO Scott Hammond in
response to my query about whether projects based on the
fork would be able to enter. “This is a Node.js project
for Node.js innovations.”
I'm not sure I can take the criticism seriously after seeing the source.