Node.js is forked, not fucked

http://wesleyio.tumblr.com/post/104637877991/node-js-is-forked-not-f-ed

by josep2 • 12 years ago

138 68 12 years ago

wesleyio.tumblr.com

NietTim• 12 years ago

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

mcantelon• 12 years ago

Possible community fragmentation until one fork "wins.

thefreeman• 12 years ago

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.

pixl972• 12 years ago

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

dragonwriter• 12 years ago

Well at a minimum you are dividing the development efforts between two different pieces of software.

Well, no. Because the realistic alternative to forking isn't that the people with irreconcilable differences that led to the fork continue working on the same code base, its that some subset of them abandon the code base altogether. Forking -- especially when the forks are under compatible open source licenses and useful code that is compatible with the vision on both sides of the divide can migrate from one fork to the other -- potentially increases, rather than decreases, the effective development effort on both sides of the forks compared to what it would otherwise be.

snlacks• 12 years ago

The reason why it seems like a really bad thing in this case: many top contributors left node over some core principles.

But I agree with the article, when you read deeper into the comments and commits, it's not virulent in the record (though I'm sure tempers flared).

That being said, I'm just a lowly web dev and barely understand what's going on under the hood.

skaplun• 12 years ago

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

debacle3• 12 years ago

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• 12 years ago

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• 12 years ago

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

andyidsinga• 12 years ago

YUP! -- when I heard it got forked my first reaction was "great, good luck to them, I'll continue to use node, imagine moving to Go and maybe in a year I'll hear about iojs if it goes anywhere"

Cheers to the iojs guys.

(ps. I have to admit, I hope to see more blog posts on these subjects creatively include "motherforker" in their titles)

wesleyfsmith2• 12 years ago

I think the linux comparison is quite apt. Even now, there are multiple distros that all use the same package format, deb or rpm. They are different forks of linux, but they've made a point to still have interoperable packages with one another.

donpark• 12 years ago

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.

tyilo• 12 years ago

Link should be changed to permalink: http://wesleyio.tumblr.com/post/104637877991/node-js-is-fork...

bsg75• 12 years ago

“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)?

iancarroll• 12 years ago

At least for now, iojs works with node and node works with iojs. They're also managed by different people.

lbotos• 12 years ago

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

debacle3• 12 years ago

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?

diminoten• 12 years ago

It'd be a very similar experience for users, where IO code/packages would be incompatible with node.js code/packages despite being, on their face, very similar.

But you're right, that situation might not last as long, due to the fact that one is theoretically trying to eat the other's users, rather than in the case of Python, where things are much friendlier.

schnevets• 12 years ago

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.

aikah2• 12 years ago

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

BinaryIdiot2• 12 years ago

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.

nawitus2• 12 years ago

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

munificent• 12 years ago

Better performance, debugging, and a simpler developer iteration loop for polyfills that require a compilation step.

nailer3• 12 years ago

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

venomsnake• 12 years ago

Performance comes to mind. Robustness too.

bsimpson2• 12 years ago

FWIW, https://github.com/petehunt/node-jsx will let you use many of the JS Harmony features (lambda arrows, destructuring, concise method notation) in Node today.

These are all the sugars that are available:

https://github.com/petehunt/node-jsx

BinaryIdiot2• 12 years ago

That looks pretty nifty; I don't have an immediate need for it yet but I'll definitely check it out. Thanks!

tracker12• 12 years ago

There's already some of that... there are packages/tooling built aroud co/koa with features that you need the latest 0.11.x and --harmony to use.

I like a lot of the ES6 features... to ES7, if await/async can be introduced with thenables sooner than later, it will mean that co will become irrelevant for the most part, and a lot of tooling around a koa2 will be awesome. There's a lot to be excited about.

chrisabrams• 12 years ago

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.

cgtyoder• 12 years ago

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

bcantrill2• 12 years ago

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

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

DCoder2• 12 years ago

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.

bcantrill2• 12 years ago

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

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

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

[4] https://github.com/joyent/illumos-joyent/tree/master/usr/src...

aikah2• 12 years ago

What is node core devs relationship with V8 team and Google,if there is any?

That's what makes me the most worried with nodejs.It depends on a project led by a corporation that is difficult "to read".We're not talking about a C++ lib that has been stable for 20+ years,but something that is likely to change fast and frequently,which will break every native extension written for node.

It seems to me that Goggle isnt that implicated in node development.

wesleyfsmith2• 12 years ago

Thank you! I'm glad we were able to share a brain wave. I'm loving the term 'forkophobia', and the comparison to Berlin. Freedom to choose means that people will gravitate to the best ideas. At the end of the day, everyone wins with open source.

iends• 12 years ago

It seems to be the issue is a little more than "more frequent releases" but is instead more about the poor stewardship of Node.js by Joyent. It seems to be about increasing transparency and openness instead of just tracking v8 more closely.

Between io.js and node-forward it seems to be working. Hopefully things like the node advisory board are just one step in Joyent being a better steward.

jpmonette• 12 years ago

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

jld• 12 years ago

I prefer a different promise of the the future.

rybosome• 12 years ago

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.

percept• 12 years ago

I'm going to defer responding.

emgee3• 12 years ago

Just a quick q: does it involve a bluebird on your shoulder?

femto113• 12 years ago

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• 12 years ago

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.

jvickers• 12 years ago

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.

lafar6502• 12 years ago

https://www.youtube.com/watch?v=HDZs0S7qd64

ahutch• 12 years ago

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