Live data from Hacker News

Io.js and Node.js reconciliation proposal

github.com

21–30 of 83 posts

Re: Io.js and Node.js reconciliation proposal

#21
post #10
post #9

Earlier quoted context omitted.

Well, considering the issue was created 6 minutes before you posted this comment, this is facetious and disingenuous.

I didn't notice that - but 42 minutes later I think the comment still stands :) 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.

Just because no one has had the time to read the whole thing, think deeply about his position and state it in the last hour proves nothing.

Re: Io.js and Node.js reconciliation proposal

#22
post #14

Earlier quoted context omitted.

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…

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.

Re: Io.js and Node.js reconciliation proposal

#23
post #10

Earlier quoted context omitted.

I didn't notice that - but 42 minutes later I think the comment still stands :) 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.

Just because no one has had the time to read the whole thing, think deeply about his position and state it in the last hour proves nothing.

Ok. Here are some issues from joyent/node that have not gotten any comments in over a month:

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

Re: Io.js and Node.js reconciliation proposal

#24
post #11
post #6

Earlier quoted context omitted.

isn't the reason io was formed because node was so outdated? It had a way old version of v8.

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

Re: Io.js and Node.js reconciliation proposal

#25
post #17

Earlier quoted context omitted.

They have to merge otherwise one will die. There is no alternative. I hope it happens sooner rather than later.

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?

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.

Re: Io.js and Node.js reconciliation proposal

#26
post #14

Earlier quoted context omitted.

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…

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.

Re: Io.js and Node.js reconciliation proposal

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

Re: Io.js and Node.js reconciliation proposal

#28

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.

They have to merge otherwise one will die. There is no alternative. I hope it happens sooner rather than later.

[deleted]

Re: Io.js and Node.js reconciliation proposal

#29

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.

[deleted]

Re: Io.js and Node.js reconciliation proposal

#30
post #17

Earlier quoted context omitted.

They have to merge otherwise one will die. There is no alternative. I hope it happens sooner rather than later.

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.

Post reply on HN