
Node.js is forked, not fucked - josep2
http://wesleyio.tumblr.com/post/104637877991/node-js-is-forked-not-f-ed
======
bcantrill
This piece is (by far) the best written on the io.js fork and its
ramifications. As I have said many times before, we are forkaphilic[1] --
forking is healthy because it allows (and encourages) experimentation with
divergent ideas. The primary idea that io.js appears to be experimenting with
is "more frequent releases", in particular very closely tracking V8. This is
somewhat ironic because the close tracking of V8 has been a major contributing
factor to the delay in 0.12: despite good intentions, V8 breaks node.js
frequently -- and debugging those problems is a time-consuming and arduous
task requiring a great deal of technical sophistication. We have made clear
that our technical priorities for the project are production-grade stability
and performance; to the degree that other have different priorities, forking
should be encouraged. In part to allow cross-pollination from any fork, we
eliminated our CLA earlier this year[2]; the community can rest assured that
good ideas from either will be able to be in both.

[1]
[https://www.youtube.com/watch?v=Pm8P4oCIY3g#t=23m43s](https://www.youtube.com/watch?v=Pm8P4oCIY3g#t=23m43s)

[2] [https://www.joyent.com/blog/broadening-node-js-
contributions](https://www.joyent.com/blog/broadening-node-js-contributions)

~~~
DCoder
> _despite good intentions, V8 breaks node.js frequently -- and debugging
> those problems is a time-consuming and arduous task requiring a great deal
> of technical sophistication_

Can you provide some examples? I'd love to see some debugging war stories.

~~~
bcantrill
TJ can provide examples from his perspective; my personal examples are all
from keeping the node.js production debugging facilities[1][2] operating
properly. We have tried hard to make these facilities independent from V8, but
the reality is that they encode how V8 operates and that changes to V8 can
break them. Fortunately, the node.js DTrace ustack helper[3] -- by far the
more intricate piece -- hasn't needed major maintenance, but the facilities
for iterating over all JavaScript objects from a core dump (for example) have
been broken quite a few times. I'm afraid the war stories from debugging these
aren't terribly heroic -- they boil down to one of the node.js debugging tests
failing and Dave Pacheco or me (exactly which one frequently being adjudicated
by fingers-on-noses) sitting down for several intense hours to learn how V8
has changed and modify our debugging support accordingly. If you want to see
the details of the changes needed to accommodate V8, you can look at some of
the specific commits for the debugging support.[4]

[1]
[http://www.joyent.com/developers/node/debug](http://www.joyent.com/developers/node/debug)

[2]
[http://www.slideshare.net/bcantrill/goto2012](http://www.slideshare.net/bcantrill/goto2012)

[3] [http://dtrace.org/blogs/dap/2013/11/20/understanding-
dtrace-...](http://dtrace.org/blogs/dap/2013/11/20/understanding-dtrace-
ustack-helpers/)

[4] [https://github.com/joyent/illumos-
joyent/tree/master/usr/src...](https://github.com/joyent/illumos-
joyent/tree/master/usr/src/cmd/mdb/common/modules/v8)

~~~
DCoder
Thank you, I will definitely check those out.

------
debacle
Forking is healthy. In the late 90s/early 00s, you'd hear about a new Linux
fork almost every other month. Those forks would die quickly, but sometimes
would have something to contribute back to the larger distros.

The fact that Node is popular enough to fork is a good thing. There is an
inherent disagreement between Joylent and the Io.js folks, not on technology
but process, and it's likely that the conflict will be resolved that way they
always are (the more suited fork will win out). The risk of fragmentation is
very low.

~~~
pjc50
There were some notable fork successes which overtook the original; egcs is
the one that comes to mind. There's still a huge variety of distros, mostly
RPM-based. And the three BSDs. And Lucid/Xemacs.

~~~
pekk
To clarify, Xemacs is a fork, but almost nobody uses Xemacs any more.

------
BinaryIdiot
The only thing I worry about is while packages will be npm compatible, if they
want to take iojs to another level as far as features go you will then have
npm packages that either only work on iojs or you will have polyfill libraries
for iojs features to work on node.js.

Yeah this doesn't mean node.js is "fucked" but if they use npm in iojs with
packages that take advantage of new API calls any node user is going to have
lots of issues.

Edit: Having said that I am excited to possibly get newer versions of V8
server-side; I can't wait to start using some ES6 in a place where I don't
have to wait for browsers to update.

~~~
nawitus
If you can implement the new features with polyfills, why do you need io.js in
the first place?

~~~
nailer
Having them used out of the box would make them more robust.

~~~
jessaustin
NPM dependencies are a very robust method for ensuring that a module has what
it needs to function "out of the box". What else are you looking for here?

~~~
nailer
Do you mean to reply to me? I made a commeny about innovation in the stdlib
would be good. and I'm quite happy with io.js supporting npm.

~~~
jessaustin
_> >>>If you can implement the new features with polyfills, why do you need
io.js in the first place?

>>>Having them used out of the box would make them more robust.

>>NPM dependencies are a very robust method... What else are you looking for
here?

>Do you mean to reply to me?_

In light of nawitus's comment, I interpreted your comment as an alleged reason
IO would be necessary, given the existence of polyfills. This reason didn't
make sense to me, because npm dependency installation for node is just as
automatic as anything in IO could be, whether it uses npm or not.

~~~
nailer
io.js is doing new things, they might be polyfillable on top of node, but more
people will use new versions of inbuilts like 'process' of 'fs' if they're in
io's stdlib than if they're in some optional module people could (but probably
won't) install on node.

------
donpark
Forking is forking. Most forks are benign. Some forks may turn out good. Some
may turn out bad. Forking is neither good or bad. Forking is forking.

------
chrisabrams
It's easy to paint Joyent as the issue, but the root cause is the core
contributors are split on their expectations and how they choose to handle
them.

------
schnevets
Sounds like a healthy split to me. Let Joyent handle the risk-averse companies
that require a stable tool, and let the community explore the future of V8
server-side javascript. I'm sure some of iojs' successes will find their way
into node.js as well.

~~~
aikah
> Let Joyent handle the risk-averse companies that require a stable tool.

Node is stable.Like too stable without even hitting v1.

I remember a video where Douglas Crockford predicted that,saying Joyent
behavior has been childish.

[http://youtu.be/8HzclYKz4yQ?t=22m32s](http://youtu.be/8HzclYKz4yQ?t=22m32s)

------
bsg75
> “The last thing we want to have happen to the Node ecosystem is to create a
> Python 2, Python 3 situation”.

As a long time Python user unhappy with the 2 vs 3 thing, is not the Node vs
IO thing very different? A fork (Node) vs two versions being managed by the
same group (Python)?

~~~
lbotos
It's different but if IO/Node diverge too far, it could break packages.

~~~
debacle
They're both MIT and likely to stay MIT. They don't have to diverge at all
unless Joylent goes open/closed.

Edit: Downvoters, have I said something that is untrue?

~~~
bsimpson
The whole debate is over uptake speed. If async functions and lambda arrows
land in IO and I use them in my package, people on node v10 aren't going to be
able to use it.

If Joyent accepts new features as quickly as IO, there's no point in the fork.

Essentially, there's bound to be some level of fragmentation.

~~~
jessaustin
What this scenario means is that there should be a way for a module to depend
on polyfill modules, _only for particular engines_. So on IO the dependency
would not be in effect, while on e.g. node v0.10 it would. I don't think this
is possible now, but you could just publish two modules.

------
jvickers
With both libraries MIT licensed, there could easily be movement of code from
io.js to node.js once the team at Joyent were satisfied that the code has been
done correctly.

I fail to see how there can be controversy over forking MIT licensed software.

------
femto113
Very reminiscent of merb (a wycats led divergence from Rails from about 5
years ago). I expect a similar arc for io.js: a couple of distinct technical
fetures that lead to a brief period of rising developer mindshare, then in a
upcoming version node.js will promise to embrace/extend whatever makes io.js
"better" and the project will peter out.

~~~
ksherlock
It's not technical features so much as an open governance.

More apropos is egcs, where the FSF eventually abandoned their gcc and blessed
egcs (and their maintainers) as the official gcc.

------
NietTim
This is the first time I read about this drama, can somebody explain to me why
getting forked is bad thing..?

~~~
thefreeman
Well at a minimum you are dividing the development efforts between two
different pieces of software. Which means (arguably) net contributions for
either one should be less then if all contributions were going to a single
project.

~~~
pixl97
Forking is the sexual reproduction of the software world. Yes, just like the
living world it takes a lot more resources to reproduce in this method, you
end up with a much larger number of variants. These variants can fill various
niches, such as security, speed, or ease of use. Most variants will get
neglected or die off, but many will succeed, and some may be reincorporated
into the original project (cross-breeding).

~~~
JoeAltmaier
Wouldn't forking be asexual reproduction? Only one parent...

~~~
jebus989
But asexual reproduction can also be known as cloning! Just a bad/unfortunate
analogy.

------
jpmonette
"The future of javascript looks bright, sunny, and full of callbacks. I’m
excited." <\-- Great opening

~~~
jld
I prefer a different promise of the the future.

~~~
rybosome
There's no way to work "coroutine" into a natural-sounding sentence, but
that's Brendan Eich's vision of the future of async handling in JS.

------
lafar6502
[https://www.youtube.com/watch?v=HDZs0S7qd64](https://www.youtube.com/watch?v=HDZs0S7qd64)

------
ahutch
does anyone know where Ryan Dahl is these days? I'd be interested in what he
has to say.

------
tyilo
Link should be changed to permalink:
[http://wesleyio.tumblr.com/post/104637877991/node-js-is-
fork...](http://wesleyio.tumblr.com/post/104637877991/node-js-is-forked-not-f-
ed)

------
cgtyoder
I was expecting a screed against juvenile sexual innuendo, but this was good
too.

------
skaplun
One guy gets paid to write about meaningless micro trends, another guy gets
paid to blast him. Nothing to gain from this in my humble opinion

