Io.js community thoughts on reconciliation | Hacker News Reader

Io.js community thoughts on reconciliation

github.com

89 pointsyvoschaap239 comments

Reading through the posts, this one struck me as the best solution...

"Personally, what I would love to see is io.js take the Node name and handle all of the development through the community. Joyent could then select specific releases that they will support as LTS for enterprises, complete with the requisite paid support packages. That seems like it might be a scenario where everyone could win."

Not only is it a practical solution that fixes problems on both sides, there are examples of similar arrangements that have worked out well, such as the symbiotic relationship between RHEL and Fedora.

That's what happened with GCC and EGCS. Tired from GCC's slow development, some developers created the EGCS fork. After a couple years, the EGCS fork became the official FSF GCC. A detailed history is here:

http://www.softpanorama.org/People/Stallman/history_of_gcc_d...

Interesting, didn't know that, thanks cpeterso.

Politics and "what it may mean for the future" talks aside, are there any API / performance / engineering differences between io and node today? I mean, there's a lot of talk regarding why joyent is bad or how joyent did nothing wrong, but from a js user's point of view, I'm rather more interested in the tangible non-human differences in node and io.

In short, speed of development and the open governance structure seem to be the two key advantages of io.js.

io.js is on a very fast release cycle using semver for versioning. The don't maintain the node.js concept of a "stable" and a "development" build (e.g., 0.10 and 0.11). Node.js developers want to use a "stable" release in production, and so were stuck on 0.10 for over two years.

io.js is integrating the latest v8 and libuv releases, giving developers access to new ES6 features (and enabling stable ES6 features by default). Node.js developers as stuck on an old V8 with poor ES6 support, requiring transpilers like babel.

io.js also now has significantly more core contributors than node.js. For what I understand, Joyent only had 1 dedicated node core developer for a long time.

Node.js current uses an unmaintained version of v8. io.js v8 is more up to date and they seem to have a better relationship with Google v8 team.

If you look at the git history of the two projects, the Node.js project contributions have slowed down drastically, while many of the active developers have been contributing to io.js instead. This means more stability in terms of bug fixes and also more features

This graph says it all: https://camo.githubusercontent.com/4e8294e5bf159efd81ba19d44...

Is there any obvious reason why they are so behind on v8 versions? It feels like that would be pretty much in the top 2 things you need to do as a maintenance part of being in "control" of node.

The V8 team's number one priority is Google Chrome. They don't really care much about supporting node, io.js, or any of the other projects that use V8.

As such, APIs break/change often from release to release which makes it hard to keep up. This is made worse by the fact that old versions are completely unsupported.

This isn't really the V8 team's fault - this is just what they are paid to do. And to be fair, V8 is frequently used outside of Chrome because it's the best JS engine around.

In practice, Mozilla's Spidermonkey and WebKit's JavaScriptCore offer comparable performance to V8, and they tend to have less breaking changes.

But V8 is definitely the engine that has the best marketing. Chrome 1.0 launched with that great comic by the legendary Scott McCloud [1], where several pages were spent on explaining JS engine performance -- something that most people had never thought about before... Ever since then, it seems like many assume V8 remains unique regardless of what's happened in the real world.

[1] http://www.google.com/googlebooks/chrome/

I agree -- I think you would be hard pressed to find substantial differences if you ran on top of SM, for instance. It was more than just marketing at the time, though. JSAPI (Spidermonkey's API) was C based and had a lot of pre-processor macro cruft at the time V8 came around and from the embedder point of view V8 was nicer to work with. Probably the biggest practical difference was that V8 exists in a separate repository. Spidermonkey must be pulled out of mozilla-central, and requires files in directories outside of js/src to build. Since Node (and other projects) embed V8 in their repos, it is more work to rip out Spidermonkey and keep it up to date. (source: I work with Spidermonkey a lot :))

JXcore is fork of Node that supports either V8 or SpiderMonkey. I suspect neither the Node or io.js developers are interested because they don't want the extra maintenance costs of supporting more platforms and abstraction layers. However, decoupling your product's core from its third-party dependencies is usually a good idea. V8 API and ABI changes have been enough a problem that someone created the NaN library (Native Abstractions for Node.js) to help Node plugin maintainers.

https://github.com/jxcore/jxcore

https://github.com/rvagg/nan

Thanks for the info!

The third-runner JavaScriptCore has always been pretty good about embedding, though. (Apple has offered it as a separate framework with a stable API since 2004 or something.)

It seems to me that the reason why Chrome went with the in-house V8 rather than just improving JavaScriptCore wasn't so much technical as political. Ultimately they ended up forking the entire WebKit too.

Mozilla was bitten twice by its poor embedding support: Gecko vs WebKit and SpiderMonkey vs V8. The Servo team has learned this lesson and is making its embedding API a high priority.

This really makes me glad I'm not betting any of my critical projects on node js. To be told that certain things can't happen because some other party has broken/stopped maintaining the most critical piece of back-end infrastructure in the entire stack...wow.

Honestly, this is akin to betting all your marbles on Microsoft not breaking or forever maintaining VB6. Kind of insane to me.

As far as I know (I'm quite new in Node), io.js wants to join the ES6 pretty soon, and most of the developers have gone to io.js from Node.js. So, while there might not be a big enough difference right now, if they continue separated there will be soon enough.

Huh?

No, io.js is a fork of joyent/node by many original core contributors. io.js has more es6 support since it's based on a newer version of v8.

Development on joyent/node slowed to a crawl and now the NodeFoundation is begging the io.js developers to return. If things remain separate, joyent/node will probably not progress much more and eventually everyone will view io.js as the "next" version of node.

Divergence is what we are worried about. I am hoping they come back together with the io implementation being the bleeding edge going back into node stable.

Not so sure about that being the best way. I agree that it would be the best for not confusing short-term. However, there are also many problems with that approach, mainly that Node.js is not of the community, it is from Joyent. While this works great in some cases (Linux), there were apparently many problems with Node.js.

I think the best would be:

1. Joyent giving the name to io.js so they can keep developing Node.js at a fast speed while keeping the name to avoid confusion.

2. As 1 is highly unlikely, IMO the best next thing is for io.js to gain market and popularity as fast as possible.

io.js isn't very bleeding edge though. That's just FUD.

Despite the submitted title, the ticket history seems more like a discussion soliciting additional feedback, implying that a decision has not yet been definitively made.

Is that accurate? Or is the weight of the io.js community on-board and we're only reading a vocal minority's opinion in the github ticket?

You are correct, no decision has been made as of yet.

I rather like the idea of io.js being a faster moving fork of node. Hopefully a "reconciliation" would mean essentially re-naming the projects to something like "node stable" and "node edge" but maintaining both, since depending on your needs you might choose one or the other.

But that's not what it is. Io.is uses the currently supported version of v8 while node doesn't; so it wins on features AND stability.

That's not necessarily true. Some of the stability comes from the bindings and interface between v8 and node. So updating v8 could temporarily decrease stability.

> Joyent have squandered much of the trust and respect they once had and they continue to frustrate even in their involvement in the AB and Foundation discussions. Does their re-involvement in this community have an impact or do we imagine they will once again become the constructive force they used to be or perhaps they will be neutralised in a way that everyone's happy?

What's this all about?

Joyent practically stopped development on node.js. They promised a 0.12 stable release repeatedly over 2 years before it was finally released. Joyent also has gotten into squabbles with StrongLoop over contributions to node.

It reminds me a lot of embrace, extend, extinguish employed by Microsoft.

Once they got platform adoption and popularity, it's like they stopped investing in the platform.

At least that's my perception as an outside user.

eh, this sounds more like an "embrace and ignore" situation (like IE6). The "extend" was about adding new features that were incompatible with the existing standard (which would in turn lead to the existing standard being "extinguished" because MS was so dominant that whatever they pushed would become the new defacto standard over whatever they "embraced" in the first place).

I wonder why they (both node.js and io.js) chose to use processes instead of threads to do multiprocessing, because with threads you can have at least structural sharing of immutable data structures.

There is an open pull request that adds "workers" to io.js, uses threads - https://github.com/iojs/io.js/pull/1159

Ok, good to know, thanks.

The title should be something to the effect of "io.js contributors weighing pros/cons of Node.js merge"

Reconciling makes it sounds like they are merging. From the posts I've read in that thread, it seems like they're as far apart as ever.

Most of the discussion seems to be "we shouldn't reconcile".

Thanks, we updated the title.

If we use the string 'dang' in a comment, does he appear?

This title should be changed......

Node seems to have tons of controversies around it ever since its inception.

As much as I would love to enjoy Node, I can't. It's just too much drama around it.

Strongloop, Joyent, none of these companies are guiding the Node community in the right direction (the Node community itself probably are too full of "strong opinionated" individuals that caused further drama).

Strongloop is basically a bunch of people with money, hired a few Node core contributors to get street creds (of course the Node core contribs people would be more than happy to get paid and be the face of a company... y'know, ego and money) and try to be the RedHat of Node (oh, they bought NodeFly and laid everybody off ).

Joyent saw "gold" in Node but it's quite clear they're having hard time to capitalize their first-mover advantages. Maybe Accounting still doesn't like the idea of paying a bunch of people with money to support an "open source project" and figure out how to make money later on.

Hence we're seeing how Joyent just didn't own NodeJS and leave everybody to dust with tons of contributions... if you want to own an OSS project, invest tons of resources, make sure you own a large percentage of the codebase, deliver tons of new and exciting features, put lots of marketing behind it, and make sure people have hard time to "catch up" thus creating an invisible barrier to enter. Hire the smart ones that still can somehow understand the codebase and contribute effectively. Another way is by providing sub-par documentation for the public to contribute, of course that's more "evil" than making it hard for individuals to get to know the codebase...

Now we have IO.js, a "community" driven with individuals who "work for corporation with Node interest" behind them...(those APM companies and Node-based service providers wanting to be the recognized leader in Node).

Let's be honest (and be real): Node is positioned to be the next popular framework after Rails. It's not hard to see why there are so much politics around it. The difference is that Rails has DHH as BDFL and he didn't want to make money out of Rails (if you don't count public speaking...) and Node has no BDFL...

>The difference is that Rails has DHH as BDFL and he didn't want to make money out of Rails (if you don't count public speaking...) and Node has no BDFL...

Node has had a few BDFLs in its lifetime: Ryan Dahl (2009-2012), Isaac Schlueter (2012-2014) and TJ Fontaine (2014 onwards)

Almost all of Node's problems stem from Joyent. They're just incompetent at stewarding the Node project.

Reply on news.ycombinator.com