Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Io.js and Node.js reconciliation proposal

github.com

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Io.js and Node.js reconciliation proposal

#61

Post by ac360 »

jballanc wrote: post #55
ac360 wrote: post #49

Earlier quoted context omitted.

Political competition is hugely important. Governance models are tech.

What? No. 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 mainl…

The path is technical, the goal is technical. Teams are involved so both are also political.

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.

Re: Io.js and Node.js reconciliation proposal

#62

Post by ac360 »

Demiurge wrote: post #52
codyps wrote: post #39

Earlier quoted context omitted.

Competitive pressure isn't just useful for commercial projects, it is also useful for open source projects.

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.

Awesome points :)

Re: Io.js and Node.js reconciliation proposal

#63

Post by dsp1234 »

falcolas wrote: post #24
inglor wrote: post #11

Earlier quoted context omitted.

It still does have a way old version of v8 that's unsupported by Google. For the record.

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). https://groups.google.com/forum/#!msg/v8-users/UUyavs0KtwE/d...

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)"

[0] - https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md

[1] - https://chromium.googlesource.com/v8/v8.git/+/4.1.0.21

Re: Io.js and Node.js reconciliation proposal

#64

Post by domenicd »

falcolas wrote: post #24
inglor wrote: post #11

Earlier quoted context omitted.

It still does have a way old version of v8 that's unsupported by Google. For the record.

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). https://groups.google.com/forum/#!msg/v8-users/UUyavs0KtwE/d...

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.

Re: Io.js and Node.js reconciliation proposal

#65

Post by Already__Taken »

Tarang wrote: post #60
fapjacks wrote: post #42

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 cour…

> 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.

Re: Io.js and Node.js reconciliation proposal

#67

Post by Tarang »

Already__Taken wrote: post #65
Tarang wrote: post #60

Earlier quoted context omitted.

> 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.

Re: Io.js and Node.js reconciliation proposal

#68

Post by couchand »

ac360 wrote: post #40
sagivo wrote: post #37

Earlier quoted context omitted.

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?

You just made my life sound way more awesome than it is.

Re: Io.js and Node.js reconciliation proposal

#69

Post by amelius »

drawkbox wrote: post #15

Rails and Merb did it ( http://yehudakatz.com/2008/12/23/rails-and-merb-merge/ ). 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…

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.

Re: Io.js and Node.js reconciliation proposal

#70

Post by spronkey »

ac360 wrote: post #61
jballanc wrote: post #55

Earlier quoted context omitted.

What? No. 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 mainl…

The path is technical, the goal is technical. Teams are involved so both are also political. 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.

Well, not quite. Instead of one good option you now have two less good ones. Not exactly a win.
Post reply on HN