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.
But how does one know which packages run on which platforms?
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.
Oh man I love it! There's no way Joyent is going to say yes to this, and the best part is that these are absolutely reasonable, sensible proposals. I grok that io.js core devs are totally serious about merging back into Node, but there's no way Joyent is going to go for this. I expect at best a counter-proposal (that may not even be public) that doesn't do these points justice. The ball is absolutely in Joyent's court, and whatever happens next will be at least entertaining.
I have read plenty about the io.js project's technical and political frustrations, but I have not seen much on Joyent's position. I don't understand why Joyent let Node languish when it is an extremely popular project and apparently a significant part of their business.
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.
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...
> these are absolutely reasonable, sensible proposals
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'm only a casual observer in this but to me it seems like Joyent pulled the coup. Node always used a benevolent dictator model but it seems lots of people don't like this being a corporate entity instead of some single guy to ping on github.
I know what you mean I feel the same way. I'm referring to only this proposal iojs have put forth, the proposals aren't as reasonable as claimed and joyents going to sideline it to my discontent.
Because in doing so they relinquish complete control in favor of io.js interests. I'm rooting for io.js, but this proposal amounts to what is essentially a takeover, not a merge.
Honestly, this just makes io.js look even more childish. They're issuing ultimatums without any reasonable chance of success.
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."
Such a coup does rest on most of the 359 working groups voting in agreeance according to the provisional and not yet entirely decided, declared, or ratified by-laws of the tentative constitution of the current committee's purview of the project, however.
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.
It actually is. The last two paragraphs are reworkings of Sir Humphrey from Yes Minister, a British political comedy from the early 80s that mocked bureaucracy and politics (while scarily showing it for what it really was).
Yeah this whole issue can even be interpreted as being passive-agressive. Not saying that it is, but it just has a weird feeling surrounding it, almost as if there is a huge grudge between each other, and being overly political (correct).
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".
Given that the majority of development contributers went over to io.js, it makes sense for the structure for technical decisions to more closely resemble io.js while yeilding marketting type things to the new Node.js organization.
I really hope we can see a unification of the efforts and work through the political issues. Having very talented developers working on separate codebases instead of improving one seems counterproductive.
Multiple languages coexist. Within Javascript, there are multiple module systems, general utility/polyfill libraries, test runners... for better or worse, we continue to have many alternatives for almost anything. So why not also different implementations of a language interpreter?
> Multiple languages coexist. Within Javascript, there are multiple module systems, general utility/polyfill libraries, test runners... for better or worse, we continue to have many alternatives for almost anything. So why not also different implementations of a language interpreter?
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.
Because they run the same package manager and roughly do the same thing for the same purpose? It's not a JRuby vs Rubinius debate, imo; it's more like YARV vs MRI, you just don't need both. If they were more different I'd agree.
From my limited understanding of the situation as a casual observer, I'd say the optimal (or at least simplest) outcome here would be to do an egcs/gcc-style switch where io.js is officially christened as the next Node.js, and the incumbent Node.js deprecated.
That said, I'm not sure if Joyent will be receptive to such a move.
My thoughts exactly. I think anyone not familiar with the history of GCC/EGCS would do well to read up a bit...the current node.js/io.js situation almost an exact parallel. I also hope that Joyent takes note that EGCS was probably one of the best things to happen to GCC, and that the shift in governance model is likely one of the reasons for GCC's current success.
I think you nailed it with "when it's possible." What about when it isn't? They're clearly divergent projects, so now you have to keep track of whether every npm package you use supports Io or Node, and which version of each. Package authors are now responsible for supporting one or the other, or becoming an expert on the differences in order to support both. It's a crappy burden on all parties involved.
The reason io.js was forked, in my opinion, is because a core group of very strong contributors wanted control over Node. They gained that control by forking, giving away control of the fork to the community (open governance model) and working to make the fork a superior product.
Technically, io.js' v8 version in release 1.4.1 is unsupported as well; it was released 01/07, and Google's support of v8 ends when it is replaced by the next version (their release/support cycle is 6 weeks).
I'm not sure that this is correct. io.js 1.4.1 just shipped with v8 version 4.1.0.21[0] which was released on 2/24/15[1]. Additionally, the post which you quoted specifically says that "4.1 -> Chrome 41" and "and every branch's support period is also the same (another ~6 weeks until the next Chrome version goes on the stable channel)."
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)"
Incorrect. We support the V8 versions shipping in stable Chrome and, to some extent, onward. Per http://omahaproxy.appspot.com/ current Chrome is on 3.30.33.16, so we support that. 4.1 is not quite supported yet, but it's actually ahead of the curve, not behind.
Open source competition can be good when the differences are primarily technical (e.g. GCC vs LLVM/Clang). When the differences are primarily political (e.g. GCC vs EGCS), then the competition serves only as a distraction. As a mostly-uninvolved outside observer, this competition seems more like the later than the former.
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.
This type of competition is not good as there will only be minor differences which will confuse others. They will not be viewed as two different environments but two version of same environment. Developers will not want their libraries to work only with io when they can make it work with node with a hack. This can create situation like unix/windows compatibility. And using same package manager worsens the situation.
it's open source, not commercial. there's no point for competition. it's better to join resources and create equilibrium. the industry will need standards which will cause one project to die (sooner or later) and we will loose all the talent and energy spent there.
The joint resources/equilibrium broke down. That’s why the fork happened. It's a natural process.
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?
It's not even uncommon to have projects compete inside a company, like linux vs osx for ios in the early days. And in-house or open source competition is much better than a typical commercial competition because the good parts from all sides can be reused, lessons learned. This is why I am against software patents, too.
I hope the two groups are able to work out their differences. I would love to see some of the strengths of io.js transfer into Node.js from both a technical and organizational perspective. The io.js project has been surprisingly thorough. So far they have kept on a consistent schedule of updates, provided excellent transparency regarding their team meetings and working groups, and they have been very responsive to feedback. I still use Node.js (with the harmony flag) for my production servers in hopes that there will be a merger soon but I may be in a dilemma if it doesn't happen within the next few months.
Funny thing about trying to standardize products or frameworks - You start with one fine product. Someone wants a bit extra, so they make a fork of the project. Then someone tries to make an all encompassing product to cover all the subsets. So there is a third one out there. Now you have to maintain not 2 but 3 separate projects, and document everything. The same story happens so often, people still try.
All the core team really lacks now is the node.js label. Joyent's trademark seems weak, since the term was in prior use for commercial purposes well before they came along. A trademark challenge might be one possibility. On the other hand, name changes in other open source projects have worked out just fine.
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.
The quote in context isn't nearly as damning as GP made it out to be. It seems to me that Hammond was answering tongue-in-cheek and only meant to emphasize that his focus was on Node.js alone:
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.
That doesn't make any sense to me. If Node is good enough, or io.js is good enough, then they are no better if the other stops existing, and no worse if the other continues existing.
But both require a healthy ecosystem of packages to be any good at all. Right now the existence of io is making package authors choose to support one or the other or do the extra work to support both. Node is getting worse for that. It's a little less of a worry now that node 0.12 is out, but the politicization of the split is just going to make developers choose sides and focus their efforts on one or the other. And considering the fact that both use NPM for package distribution, package management is going to get more difficult, not easier.
To be fair, at this stage, supporting both is a bit like supporting both Python 2 and 3. The name change makes it seem bigger a split than it really is.
While slightly true, as a popular package author, it's honestly no harder than adding support for another version of node. Supporting node 0.12 was a big enough change (particularly for compiled modules) that thankfully io.js was exactly the same work and required no changes. And thankfully Travis supports both.
and it all goes downhill from there... I was never a big fan on node.js. it's mainstream popularity seems due to its corporate governance. io has just been so much more agile and faster, that I really worry that we will see stagnation now if this all goes through
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.