

Io.js community thoughts on reconciliation - yvoschaap2
https://github.com/iojs/io.js/issues/1336

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

~~~
cpeterso
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...](http://www.softpanorama.org/People/Stallman/history_of_gcc_development.shtml)

~~~
ZenoArrow
Interesting, didn't know that, thanks cpeterso.

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

~~~
iends
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

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

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

~~~
pavlov
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/](http://www.google.com/googlebooks/chrome/)

~~~
apaprocki
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 :))

~~~
cpeterso
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/jxcore/jxcore)

[https://github.com/rvagg/nan](https://github.com/rvagg/nan)

------
otoburb
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?

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

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

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

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

------
primitivesuave
> 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?

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

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

~~~
jordanlev
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).

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

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

~~~
amelius
Ok, good to know, thanks.

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

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

------
wesleytodd
This title should be changed......

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

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

