
Node.js, a popular tool for building modern internet services, has split in two - DieBuche
http://www.wired.com/2014/12/io-js/?hn
======
justplay

        >Node was created by software developer Ryan Dahl 
        as a way of building and running entire online applications
        with JavaScript—the standard programming language for writing 
        code that runs in your browser.
    

Really? I thought that they intentionally choose javascript because it doesn't
have any features like threading.

    
    
       > The massively popular programming framework Ruby on Rails, 
       for instance, is still sponsored by its creator, a company called Basecamp.
    

Basecamp isn't happy to the direction that ruby on rails is going, but they
accept it. [1]

[1]:
[https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be...](https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be&t=11m13s)

~~~
drderidder
It's a widely held misconception that JS doesn't have threading. User code
executes in a single thread, but asynchronous tasks are managed by a thread
pool (libuv in node). Because the multi-threading is hidden with asynchronous
calls, the user doesn't need to worry about it, which is why many people say
JS is single-threaded. In fact worker threads execute async tasks behind the
scenes; it's a very nice feature of the event-loop architecture.

~~~
flebron
You may be speaking of a particular implementation or engine. JS, the
language, has no such concept of a "thread". The standard describes execution
of a valid program as linear. Libraries may add functions such as event
listeners or threading or sockets, but these are not part of the language.

And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by
JS you mean JavaScript the implementation by Mozilla, then Node doesn't use
that anyway :p

~~~
joshuacc
Well, there are Web Workers, which are basically threads.
[http://www.html5rocks.com/en/tutorials/workers/basics/](http://www.html5rocks.com/en/tutorials/workers/basics/)

But it appears that it's part of the WHATWG HTML spec rather than ECMAScript,
which is a bit weird.

~~~
jerf
Web Workers are closer to "processes" in the Erlang sense of the term. They're
walled off fairly extensively from the rest of the JS runtime that spawned
them because that is pretty much the only good way to backport threading onto
a language that wasn't designed with it in mind from the beginning.

Languages like C which had them bodged on years later, well, I'd call that a
_bad_ way to do it. It worked for the time but there's a reason why we are all
fleeing that implementation of threading and it still stains the entire idea
of "multithreading" decades later.

If JS is _ever_ going to get threading, the best case scenario is for it to
look like Perl or PHP's efforts... years and _years_ of implementation work to
get to something that pretty much everybody recommends you still just stay
away from. And Perl and PHP were trying to integrate threading into just one
runtime each, and without a browser connected at the hip with its own ideas
about threading embedded into decades of code. I would not hold your breath
for "true" JS threads anytime soon.

------
zkhalique
I think the intersection of politics and internet is interesting. I write
about it quite a bit on my blog, as well as here:
[http://qbix.com/blog/index.php/2013/04/a-new-kind-of-
platfor...](http://qbix.com/blog/index.php/2013/04/a-new-kind-of-platform/)

In this case, we see sort of an "arab spring" of open source projects lately.
Consider MySQL after it was bought by Oracle, and then the MariaDB fork was
born. Now we have Node.js and Docker being forked. Until now, most successful
communities have been monarchies or oligarchies, whether it was Linux or
Python. Corporate sponsorship played a big role. But if more headless or
democratic communities succeed, it will be interesting to watch. PHP is an
example of a more headless community, and it used to be all over the place.

There are two ways politics and internet interact. One way is how the tools we
use affect our society in meatspace and the other is how we organize online in
cyberspace.

~~~
debacle
This is more about how, for many companies, the OSS doctrine that they espouse
doesn't really jive with their need for profitability.

In the long run, they need to make decisions for the company that are not in
the best interest of the project, and either the project dies or is forked or
abandoned.

Sun did really well by the OSS community for a very long time, but they had
nothing to show for it and Oracle has since foisted a lot of their efforts on
to the ASF. LibreOffice, hhvm, Mint, just to name a few, have all come about
because the companies responsible for the stewardship of a project weren't
doing their duty in the eyes of the community. I honestly think we're going to
see a Firefox fork in the next 2-3 years.

It's just the nature of OSS and while it means that, long-term, fewer
companies will invest in the space, the companies that do invest will do it
for the right reasons.

~~~
dragonwriter
> I honestly think we're going to see a Firefox fork in the next 2-3 years.

There are already semi-forks (downstream distributions that continue to pull
from upstream and are mostly synced, but also maintain distinct and divergent
feature sets) -- both GNU IceCat is an example (Debian Iceweasel I think is
less so, because IIRC it is synced but for branding with upstream.)

~~~
bhouston
[https://www.waterfoxproject.org/](https://www.waterfoxproject.org/) as well
-- a 64 bit version.

~~~
kibwen
And another, Pale Moon: [http://www.palemoon.org/](http://www.palemoon.org/)

------
egeozcan
> Future of Popular Coding Tool in Doubt After It Splits in Two

Are there convincing number of examples of very popular projects being forked
and both ends being discontinued, or is this just a typical example of
spreading FUD?

Forking is a natural process in the open-source world.

~~~
Thaxll
But it's true that Node is losing traction.

~~~
cloakandswagger
I see this more as a return to reality from Node.js's astronomical levels of
hype.

The use cases for a single-threaded web server are specific and limited in the
real world. Node.js will continue to solve those use cases (simple web server
for static content or I/O bound apps) but the resultant decline will lead some
to believe that the framework is dying.

~~~
tracker1
Perhaps you could name some website/app servers that aren't mostly i/o (or
event-timing) bound? I wouldn't say the use cases are limited at all.

You can always run multiple process instances, and communication between
processes isn't really so different in practice than inter-server
communication... Which just means you are scaling horizontally by design
earlier in development.

~~~
cloakandswagger
I worked on some web-based project management software which was highly CPU-
bound.

A typical scenario would be the application querying a database for financial
figures, doing a large amount of calculations on those figures and then
generating an HTML report from them. I imagine any application with large
amounts of business logic like this will be the same.

~~~
jessaustin
Could you describe the sorts of calculations those were? Are these regressions
or similar? Do PMs really look at that sort of thing? Maybe they were basing a
TSP on the latest financial figures? b^)

It seems possible that was a mostly IO-bound system, and the things which
could have been conceivably CPU-bound should just have been batched and
cached.

------
wcummings
Ben Noordhuis, the center of the Node.js pronoun scandal [1] and one of the
founders of Strongloop, has activity in IO.js more recent than his activity in
Node.js.

I can't help but wonder how much of this is a power struggle between
Strongloop and Joyent.

[https://www.joyent.com/blog/the-power-of-a-
pronoun](https://www.joyent.com/blog/the-power-of-a-pronoun)

~~~
SloopJon
Off topic, I guess, but color me unimpressed by the guy claiming he would fire
someone for rejecting a pull request that does nothing but advance a political
agenda.

~~~
snowwrestler
Color me impressed, because the political agenda that's being advanced is
gender equality in technology, which to me seems pretty worthy.

~~~
jbigelow76
Problem with that situation was that the Joyent guy was commenting on
Noordhuis, an employee of a direct competitor to Joyent. So to many it came
off as political opportunism to screw with Strongloop and not a sincere
evaluation of the situation.

------
shortcircuit01
There is a big advantage to node.js that used to be mentioned a lot in its
early days, but not much now. The advantage is still there, but it's only
noticeable if a developer has experience in other server languages. The big
advantage is that node.js had an asynchronous development model from the
beginning. This caused all the code written since then to also be written
using async. When a node.js project imports other libraries through npm, there
is no need to worry about some random synchronous code blocking. All code is
written using async because that's the way it was enforced from the beginning.

This is an advantage it shares with other new languages like Go that had good
concurrency support from the start. Go has the same advantage with goroutines.
All code written by the community since then uses goroutines.

Compare this to python and java which had better concurrency bolted on long
after those languages were released. Twisted is basically node.js for python
and it existed for a long time before node.js. But one of the main problems
with Twisted is that all other existing python code is not written in an async
way. A python dev could use Twisted, but as soon as they get some useful
library form PIP, it's probably going to block and ruin the whole async.

Java has a similar issue. It was released with heavy threads as the only way
to handle concurrency. There have been attempts to try to bolt on async and
lightweight thread models. But there is a massive existing ecosystem of java
code. None of that will work well with async and no one can rewrite all of it
to use some new lightweight thread model.

This is the advantage of a fresh start like node.js or Go. Wheels will be
reinvented, but it will have improvements that can't just be bolted on later.

The biggest flaw with node.js right now is that it came too early. If it came
out with ES6, it would be a much better ecosystem. If generators/yield had
existed from the start, all the callback mess could've been avoided. However,
although the callbacks were an unavoidable mess, it did fundamentally force
async on the ecosystem. NPM libraries like co show a migration path to the
generators/yield future for older node.js code. The IO.js fork should use this
opportunity to put something like the co library into core and push
generators/yield as the way forward. If Joyent was the cause of the delayed
generators/yield support, then they have done great damage to the node.js
ecosystem. Node.js should've heavily promoted generator/yield use as soon as
it was in V8, not hide it behind a --harmony flag for over a year.

~~~
brainflake
Great comment - I do think the whole 'async by default' is a huge benefit, but
I would add an asterisk and say you can technically write a module that
performs synchronous I/O if you wanted to (see, for example, synchronous
filesystem calls). So there's a possibility some random synchronous code
blocking could happen with an untrusted module, albeit very unlikely. As far
as I know the fs.*FileSync calls are the only ones.

------
exabrial
If Node forks, does this mean one of the projects will block?

~~~
andypants
No, node.js is event-driven and non-blocking.

~~~
emergentcypher
But there is only a single thread, so io.js will probably hog all the time and
effectively block everybody else.

------
exabrial
How can Node fork? I thought it ran everything in the event loop...

~~~
binarymax
I see your bad joke and raise you an example :)

[http://nodejs.org/api/child_process.html#child_process_child...](http://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options)

~~~
exabrial
Haha! Oh man...

------
hartator
The new repository:
[https://github.com/iojs/io.js/](https://github.com/iojs/io.js/)

The new contributors:
[https://github.com/iojs/io.js/graphs/contributors](https://github.com/iojs/io.js/graphs/contributors)

Joyent really fucked up.

~~~
prezjordan
The "new contributors" link you provided uses commits from before the fork, so
it doesn't really have any information.

~~~
TimWolla
Do you know who the 4 developers mentioned are? isaacs probably is the NPM
one.

------
ulisesrmzroche
I think it's great news. Node development has been glacial for a while now.
There's an issue where people are sharing logos,
[https://github.com/iojs/io.js/issues/37](https://github.com/iojs/io.js/issues/37),
highly recommend.

~~~
esalman
Better visualization: [http://tableflip.io:1234/](http://tableflip.io:1234/)

~~~
ulisesrmzroche
Nice link! Check this one instead of mine if you haven't done so.

------
debacle
> actually set up this foundation because they’re still hoping that Joyent
> will let them to use the Node.js trademark.

Is that naivete on the side of Io.js here, or is there more to the story?

~~~
craigching
I'm not sure what you're asking, you left out the key part of the quote:

> the team hasn’t actually set up this foundation because they’re still hoping
> that Joyent will let them to use the Node.js trademark.

Frankly, I kinda like the name Io.js better than Node.js

~~~
dragonwriter
> Frankly, I kinda like the name Io.js better than Node.js

Well, if it was for a project that was implementing Io [0] on top of
JavaScript, sure. For a server-side JS stack based on V8, I don't really like
the name at all.

[0] [http://iolanguage.org/](http://iolanguage.org/)

------
JeremyMorgan
Here's a take from one of my friends who is a pretty heavy Node developer:

[http://compositecode.com/2014/12/05/im-so-mad-my-response-
to...](http://compositecode.com/2014/12/05/im-so-mad-my-response-to-the-fork-
of-node-js-to-io-js/)

I'm pretty sure he's right, nothing to freak out about.

------
bhouston
I believe given the nature of those that forked it, we'll be replacing Node.JS
with IO.JS (that is awkward to write) soon in
[http://Clara.io](http://Clara.io).

I think that the confusion around Node.JS versus IO.JS will persist for some
time though. If I wasn't a regular HN reader, I would have missed this
completely.

~~~
drderidder
You're not the only one. iojs is already pulling ahead in momentum, fixes,
features. Not to mention it has a bazillion logos to choose from haha

~~~
notduncansmith
I must be missing something. What features has io.js added?

------
anonfunction
The community has created a lot of rad logos you can find here:
[http://tableflip.io:1234/](http://tableflip.io:1234/)

------
andrewstuart2
Well now there's a missing consonant in the MEAI stack. Add golang for the
IMAGE stack?

~~~
54mf
AIME? ;)

~~~
emgeee
Oh I like that- drop the 'E' for express since it's a little redundant and you
get "AIM"

~~~
ProCynic
Hey, that's even in front-to-backend order.

------
percept
Here's your Friday entertainment...

------
username223
The guy squatting on the js.io domain (Michael Carter from Claremont) just
bought a yacht.

~~~
user_id2
That's ok since internet has been squatting on Javascript for years.

