
Node.js is Cancer - aaronbrethorst
http://teddziuba.com/2011/10/node-js-is-cancer.html
======
collypops
Reading back through some of the author's other posts, I see a common theme:

Author picks out a software developer whom he considers is Doing It Wrong
(TM), and tells them they're Doing It Wrong (TM).

The author seems to think that the world would be a better place without
Node.JS, evented IO and server-side JavaScript, and rather than putting
together a concise (or coherent) argument about the pros/cons, he decides to
go after Ryan Dahl himself. I'm tired of the number of S and F-bomb dropping,
rockstar programmer mentality-wielding morons who clog up the innovation
space, and have nothing to contribute but FUD and nay-saying.

We're developers. We create. We find itches and scratch them. Node.JS is the
result of Dahl scratching his itch, and a lot of us see merit in the project.
Some very smart people (I'm tipping my cap to the people at Joyent, here) are
actively addressing Node's rougher edges, so we'll see constant improvement.
It's still relatively young (especially compared to the holy UNIX), and so
what if it doesn't solve all of your problems; there's room for everyone to
play in the web server scene, even JavaScript.

------
enobrev
I've said it before and I'll say it again: While liking Ted's writing is a
matter of taste, he makes good points.

You probably shouldn't be trying to beat nginx or apache with node.js. That is
a solid point. A couple years ago, I would have said you probably shouldn't
try to beat Apache. I'm not saying it can't be beat; I'm saying you're not
Igor Sysoev.

Javascript probably isn't the best language for an important scalable
application on the server. It's getting better. But there's a reason Google
and friends have to make some serious improvements. Don't get me wrong, I Love
Javascript. It's one of my favorite scripting languages.

I love PHP as well (another language Ted just took a stab at). But I won't
pretend PHP will some day be the best way to make an Android app. Sure, if
someone added a PHP interpreter to Android, I might consider prototyping with
it. But when it's time to shoot for production, it's going to be Java.
Obviously.

Our languages are tools. Ted happens to think Javascript is the wrong tool -
and in most cases outside of the browser - he's probably right. I'm using it
for a pretty large project right now. I have pull requests to a few npm
modules and few new npm modules to add, and a few thousand lines of code tying
them all together.

But once our concept is proven, I assure you, Node will probably be the first
thing to go. Not from my toolbox, just from the project that will have already
outgrown it. It's not the right tool for the job when we scale beyond a couple
servers. But for right now, while figuring out what goes where and why, there
is none better.

~~~
wisty
So what's stopping you putting nginx in front of node?

If you're worried about the maturity of its library, availability of good
developers, or just that JS is an ugly language (and Coffee-script is too
boutique), or Java is just faster, that's a good reason. Though there are lots
of people who use the slow and ugly PHP (which seems to get good milage -
Facebook and Wikipedia are doing OK with it).

I don't like JS, so I wouldn't use Node, but that doesn't mean it's crap.

------
wladimir
Ok, I also cringed when reading the original post by Ryan Dahl bashing UNIX
for its "complexity". I simply assumed that he had had a bad day. But this
reply is simply mean and almost reeks of character assassination (very ad-
hominem). "cancer", he "wrote code unchecked for years", "braindead"...

Yes, an async framework is not the panacea for everything. That has been known
for a long time with similar frameworks for Python/Java/... It makes some
things easier/faster and other things harder. But why act like this?

~~~
wisty
And, as other less polite posters have pointed out, some of what he says is
debatable. I've read a few of Ted's posts, and while he's smart and a good
communicator, he is extremely narrow minded. I'm sure he has his own way of
doing stuff, and can implement like a machine using his own narrow toolset,
great. No-one can learn to use every tool, and some can just be a giant time-
sink ( _cough_ Google AppEngine). But that doesn't mean that everyone who uses
a different toolset is a complete tool.

One minute, he's ripping into Tornado, because it's under-engineered. Then he
thinks Twisted is over-engineered. Next, Node.js is crap, because it doesn't
do things _his_ way. Then there's NoSQL, which he hates, because it's not
MySQL. No idea what he thinks of PostGres, he probably thinks it's got too
many features.

Point 1: A Scalability Disaster Waiting to Happen. No, node.js is not a
scalability disaster, and even if it is, doesn't Ted advise developers not to
worry about scalability as they are only going to get ~3 long-term users in
the first year?

Point 2: Node Punishes Developers Because it Disobeys the Unix. Um, you can
put it behind nginx, and that buys you a lot of "separation of concerns".
Honestly, he mostly seems to be insulting node.js programmers, suggesting that
they _don't_ bother to create full production systems - quote "let's be honest
with ourselves here, if you're a Node developer, you are probably serving the
application directly from Node, running in a screen session under your
account." This seems to be really the core of his concerns - Node is easy for
one guy to setup a working website. Isn't that a good thing?

Point 3: It's Fucking JavaScript. Which I guess is good if you are a JS
expert.

He swings between two extremes - everyone using simpler tools than him is a
retard who needs to man up and learn to program, and everyone using more
dangerous tools should stop beating their chest and actually implement
(premature optimization, guys!) In the case of node.js, he seems to believe
both points, which I suspect is because he just doesn't like the toolset.

~~~
mgkimsal
"Node is easy for one guy to setup a working website. Isn't that a good
thing?"

Maybe. Maybe not.

Many people on this forum have had to rescue or rewrite systems that were
built in Access. Access is easy for one guy to set up a database. Isn't that a
good thing? Sometimes yes, sometimes no.

Ditto for Excel nightmares.

That said, a prime distinction between Excel/Access and something like Node
(and I'd throw Rails in there too, given all the "it's so easy" love it got a
few years ago) is open (and open source) and it's easier for the community to
work around the issues that come up, release new versions quickly, and fix the
bad parts faster than with closed solutions like Excel/Access.

But... just because something is easier to use doesn't mean it's the best tool
for all use cases - really nothing is best for all use cases. :)

Haven't done much with Node beyond Hello World stuff - tried to install and
use zombie, but couldn't get it to work.

------
mythz
Here is a perfect example of a troll artwork:

Build a straw man argument picking a useless example exploiting a known design
limitation of a particular design choice and use it to tarnish everything
about it.

Unfortunately this doesn't tell node devs anything new, fuels node haters and
presents deceptive information to devs unfamiliar with event loops or the
scalability problems inherent with Blocking IO.

------
revorad
If possible, can someone ignore the showers of vitriol for a minute, and
comment on the technical merit of his criticism of Node? I ask because I'm a
total noob and would like to understand what's being discussed.

~~~
gruseom
_comment on the technical merit_

Hi, Hrishi. There is a grain of technical merit in two of his three
objections, but he trollishly overstates them. I've had to think about some of
the same questions lately, so here are some thoughts. If anyone has a
substantially different perspective, I'd like to hear it.

By the way, the most interesting thing about his critique is that he doesn't
even touch on the most common objection to Node, that async callbacks don't
compose well and so break down under complexity. That one's been argued to
death on HN, though, so I'll follow his example and leave it out of this.

Let's consider the criticisms in reverse order. #3, about Javascript, we can
dismiss as a vacuous language flame. #2 is about separation of concerns. He
argues that web servers should be separate from web apps, and Node confuses
the two by doing web server stuff (handling HTTP requests) and app stuff
(whatever your app does) in the same context. Now you either have to put a
"real" web server in front of Node (in which case there's the question of what
value Node's adding) or use a relatively immature web server (Node itself) as
your front end. There is a good point about modularity here. But is the line
between web servers and web apps always so clear-cut? If his argument were
completely true, CGI would be perfect for everything. Most people wouldn't
agree with that. Moreover, you wouldn't see complex configuration languages
and extension APIs for web servers, the kinds of things that arise when the
lines start to blur (and are not very pleasant to work with). So the question
is just how separate the concerns really are. This surely depends on the
application. Separation of concerns is a good thing until interactions between
modules become unduly complex, at which point one sometimes gets a big
simplification by unifying them.

For example, in the project I'm working on, there are resources that need to
be requested by the browser and sometimes also by the (app) server in order to
complete some computation. You could divide this work many different ways, but
it sure is convenient to just write Node handlers to do whatever I/O you need
in the course of completing a request. To have the app server go back to the
web server would be awkward, and so would having two different ways of
fetching the same stuff.

#1 is about blocking. He refutes a blurb that says "nothing blocks in Node" by
showing a trivial example that indeed does block Node by doing a long
computation in an event handler. (One wonders why he didn't go full retard and
just put an infinite loop in there.) This is a deliberate misreading of the
blurb, which obviously meant not " _nothing_ blocks" but "no I/O blocks". So,
a straw man. But dig deeper and there is a valid point nearby. If you have
long computations to do while fulfilling a request (where "long" is defined as
"taking longer than you're comfortable having all other requests to this
server wait"), then for Node to work well, you have to farm those computations
out to other processes. This is doable, but adds complexity. You start to move
out of Node's sweet spot.

What's the sweet spot? If writing your server code in Javascript is a win for
you and your app is I/O bound (more precisely, if there aren't any long-
running computations as defined above), Node looks pretty good. If in addition
the app server and web server have more complex interactions than just "here's
your request" and "here's your reply", it starts to look really good. An
example might be a web chat app.

As things get more complex, the judgments get trickier. In our case, we do
have long-running computations. Bad for Node. But we also have webserver-like
needs in our appserver, a lot of I/O that we don't want to block on, _and_
Javascript is a big win for us. So on the whole Node wins. Take away the point
about Javascript, though, and it probably wouldn't.

------
SamReidHughes
What a stupid asshole. How else would you expect an event-driven server to
behave when you throw Fib(40) at it? The only legitimate complaint entangled
in that strewn-out plesh of vitriol is that Node's http server doesn't have
some features that one might like in a web server. Putting a proxy in front of
Node is not a problem, because Node's strengths (handling zillions of
connections with little memory overhead on top of application state, without
having to write your own event system) are not abated.

~~~
BarkMore
Although it's expected that long calculations will block a Node server, the
complaint is legitimate.

~~~
bunderbunder
The only thing he legitimately did was build a straw man and knocked it down.
If a programmer doesn't know how his tools work well enough to foresee any
potential gotchas and take steps to avoid them, that's a fault in the
programmer rather than the tools. Not a terrible fault; any programmer who's
honest with himself will acknowledge that he does this fairly often;
especially when he's learning new tools. And will respond to the situation by
learning from mistakes and writing better code in the future, rather than
writing breathless blog rants that smell of (to use the author's language)
butthurt.

Alternatively, we could interpret the article to be based on the assumption
that it's common for people whose knowledge of how computers work is so poor
that they believe everything north of the southbridge happens instantaneously
to be put in charge of making major design decisions for high-traffic sites.
But that seems less charitable to me, since it replaces a simple straw man
with something approaching delusional paranoia.

~~~
phamilton
Guess what! You agree with Ted then. One of the big problems he mentions is
the apparently simplicity of an event driven app.

"Because nothing blocks, less-than-expert programmers are able to develop fast
systems."

That's bit he has a problem with. From your post:

"If a programmer doesn't know how his tools work well enough to foresee any
potential gotchas and take steps to avoid them, that's a fault in the
programmer rather than the tools."

Both of you are saying that a programmer needs to know his tools well. Ted
says that Node.js doesn't encourage people to understand the limitations of an
event driven framework well enough.

All you good programmers out there: Keep using Node.js. It is a great tool and
does things well. But don't pretend that it's the snake oil to make everything
faster. The design decisions YOU make have the most impact on the speed of
your application.

------
rryan
I normally like Ted's posts, but in this one he either omits or doesn't seem
to realize that the reason nginx scales better than Apache is that its workers
are non-blocking event-loops.

------
mobileman
I have to agree with him. I bought into it, but it feels like I'm getting
fucked in the ass.

~~~
andrewthemerry
Is getting fucked in the ass a good or bad touch here?

~~~
hermanjunge
Good point, man has to be specific

~~~
pyrotechnick
Point to the places on this doll where you have been fucked by node.js...

------
deleo
If I was Yahoo I'd think twice before adopting something like Node.js, but if
you're a little guy that wants to scale on the cheap and is willing to take
risks because the alternative simply won't work for what you're trying to do,
then just use Node.js. Django, PHP, Rails with Apache in front of them aren't
designed to handle thousands of persistent connections and it would be far
more expensive to scale the traditional web-stacks to handle them.

As some Joyent guy was saying there's real resources behind Node.js, it isn't
just a cool hack made by some promising Jedi but it needs to fit your use-
case. If you're designing a real-time web app and you have a limited budget
then go for it, I don't think there's anything better out there now (except
for Tornado, Twisted, which is just a matter of taste) unless you're Yahoo,
Google, etc...

------
ootachi
"if (typeof my_var !== "undefined" && my_var !== null) { // you idiots put
Rasmus Lerdorf to shame }"

Someone doesn't know about the "foo == null" idiom (it's true if and only if x
is null or undefined).

Not to mention the fact that the "typeof foo == 'undefined'" thing is overly
defensive "best practice" that people keep needlessly repeating, IMO. If
someone is stomping all over important fields of the global object, there's
nothing you can do.

JavaScript has its issues, but this one isn't fair.

~~~
stock_toaster
> Someone doesn't know about the "foo == null" idiom (it's true if and only if
> x is null or undefined).

(preface: I am by no means a javascript guru)

Really? Double equals in javascript? I thought that was a no-no due to the
type coercion that "==" does.

I get a reference error when I crack open a console and try your example
idiom.

~~~
ootachi
Right, it doesn't work when you're testing whether foo is a bound name at all.
In that case you need to use "window.foo" (or this.foo in Node).

And yeah, it's double equals. The coercion is exactly what allows "== null" to
do the right thing in the presence of undefined. Contrary to popular belief,
"0 == null", "'' == null", and "[] == null" are all false in JavaScript. "foo
== null" doesn't test for falsiness, it just checks whether foo is null or
undefined.

------
ricardobeat
So? Ted Dziuba hates node.js and thinks Ryan Dahl is a jackass.

I guess he didn't look at node for long enough to realize that it's a low
level platform, not an http web framework.

------
voidr
This is a typical troll post coming from someone who clearly doesn't
understand what he is talking about. I wonder how would he write a parallel
process manager ...

------
franze
>Node.js is an unpleasant software library and I will not use it.

a rant about a software he doesn't even use....

~~~
inaequitas
A rant about software that he _won't_ use. Clearly he has done some testing to
see how things are, but why would he use something he's convinced is crap?

------
mythz
What a retarded post from a self-proclaimed smart guy.

First he completely misrepresents the point that Node performs well and scales
is because it doesn't Block I/O, i.e. the biggest bottleneck in scaling highly
concurrent applications.

It's hard to actually pull out any facts or points to dispute since he sounds
like a whinny troll on a rant, hand picking disingenuous examples that are
obviously going to trip up event loops, something everyone programming against
an event loop already knows. A clearer example would simply be:

    
    
         while(1);
    

And the point is this blocks the server 'by design', i.e. no time is spent
context switching between threads.

If for some reason he really needed to calculate high fibonacci numbers on a
web server he could simply memoized the fibonacci function, and get back your
stellar response speeds (on a 2yo Macbook air):

    
    
            function memo(f) {
    	  return function (x) {
    	      f.memo = f.memo || {};
    	      return (x in f.memo)? f.memo[x] : f.memo[x] = f(x);
    	  };
    	}
    	fibonacci = memo(fibonacci);
    
        ~> time curl http://localhost:1337/
    	fib: 165580141
    	real	0m0.023s
    	user	0m0.009s
    	sys	0m0.005s
    

If he's going to profess CGI scripts are a superior way of doing things, I
want to see proofs/benchmarks since nothing he's said makes me take his word
on face value - that and his previous posts he shows he's an actual baiting,
troll - so I wont be relying his advice anytime soon.

And in his quest to poison JavaScript he choses an code example that no one
actually uses, since it can be expressed in the more concise equivalent:

    
    
        if (my_var != null) {
          // you idiots put Rasmus Lerdorf to shame
        }

~~~
phamilton
"if (my_var != null)" Throws a reference error if my_var is not defined. By
checking the typeof it will short-circuit before throwing the error. It is
accepted enough to be the default coffeescript implementation of "?" (the
existential operator).

The OPs point wasn't that you couldn't write faster code with non-blocking
I/O. His point was that just having non-blocking I/O isn't always going to
make things faster. Sure, most applications get lucky and have faster
implementations, but it is important to understand what is happening behind
the scenes in order to avoid hanging yourself. He thinks the Node.js community
has not emphasized that understanding at all and the hype around Node.js is
leading to badly written applications.

