Node.js is Cancer

[align=center]Node.js is Cancer[/align]

先转一下原文(原文地址似乎已不存在了http://teddziuba.com/2011/10/node-js-is-cancer.html)：
by Ted Dziuba on Saturday, October 01, 2011

If
there's one thing web developers love, it's knowing better than
conventional wisdom, but conventional wisdom is conventional for a
reason: that sh*t works. Something's been bothering me for a while about
this node.js nonsense, but I never took the time to figure it out until
I read this butthurt post from Ryan Dahl, Node's creator. I was going
to shrug it off as just another jackass who whines because Unix is hard.
But, like a police officer who senses that something isn't quite right
about the family in a minivan he just pulled over and discovers fifty
kilos of black horse heroin in the back, I thought that something wasn't
quite right about this guy's aw-shucks sob story, and that maybe, just
maybe, he has no idea what he is doing, and has been writing code
unchecked for years.

Since you're reading about it here, you probably know how my hunch turned out.

Node.js
is a tumor on the programming community, in that not only is it
completely braindead, but the people who use it go on to infect other
people who can't think for themselves, until eventually, every asshole I
run into wants to tell me the gospel of event loops. Have you accepted
epoll into your heart?
A Scalability Disaster Waiting to Happen

Let's
start with the most horrifying lie: that node.js is scalable because it
"never blocks" (Radiation is good for you! We'll put it in your
toothpaste!). On the Node home page, they say this:

Almost no
function in Node directly performs I/O, so the process never blocks.
Because nothing blocks, less-than-expert programmers are able to develop
fast systems.

This statement is enticing, encouraging, and completely f*cking wrong.

Let's
start with a definition, because you Reddit know-it-alls keep your
specifics in the pedantry. A function call is said to block when the
current thread of execution's flow waits until that function is finished
before continuing. Typically, we think of I/O as "blocking", for
example, if you are calling socket.read(), the program will wait for
that call to finish before continuing, as you need to do something with
the return value.

Here's a fun fact: every function call that
does CPU work also blocks. This function, which calculates the n'th
Fibonacci number, will block the current thread of execution because
it's using the CPU.

function fibonacci(n) {
if (n < 2)
return 1;
else
return fibonacci(n-2) + fibonacci(n-1);
}

(Yes,
I know there's a closed form solution. Shouldn't you be in front of a
mirror somewhere, figuring out how to introduce yourself to her?.)

Let's see what happens to a node.js program that has this little gem as its request handler:

http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end(fibonacci(40));
}).listen(1337, "127.0.0.1");

On my older laptop, this is the result:

ted@lorenz:~$ time curl http://localhost:1337/
165580141
real 0m5.676s
user 0m0.010s
sys 0m0.000s

5
second response time. Cool. So we all know JavaScript isn't a terribly
fast language, but why is this such an indictment? It's because Node's
evented model and brain damaged fanboys make you think everything is OK.
In really abusive pseudocode, this is how an event loop works:

while(1) {
ready_file_descriptor = event_library->poll();
handle_request(ready_file_descriptor);
}

That's
all well and good if you know what you're doing, but when you apply
this to a server problem, you've pluralized that sh*t. If this loop is
running in the same thread that handle_request is in, any programmer
with a pulse will notice that the request handler can hold up the event
loop, no matter how asynchronous your library is.

So, given that, let's see how my little node server behaves under the most modest load, 10 requests, 5 concurrent:

ted@lorenz:~$ ab -n 10 -c 5 http://localhost:1337/
...
Requests per second: 0.17 [#/sec] (mean)
...

0.17
queries per second. Diesel. Sure, Node allows you to fork child
processes, but at that point your threading/event model is so tightly
coupled that you've got bigger problems than scalability.

Considering
Node's original selling point, I'm God Damned terrified of any "fast
systems" that "less-than-expert programmers" bring into this world.
Node Punishes Developers Because it Disobeys the Unix Way

A
long time ago, the original neckbeards decided that it was a good idea
to chain together small programs that each performed a specific task,
and that the universal interface between them should be text.

If
you develop on a Unix platform and you abide by this principle, the
operating system will reward you with simplicity and prosperity. As an
example, when web applications first began, the web application was just
a program that printed text to standard output. The web server was
responsible for taking incoming requests, executing this program, and
returning the result to the requester. We called this CGI, and it was a
good way to do business until the micro-optimizers sank their grubby
meathooks into it.

Conceptually, this is how any web application
architecture that's not cancer still works today: you have a web server
program that's job is to accept incoming requests, parse them, and
figure out the appropriate action to take. That can be either serving a
static file, running a CGI script, proxying the connection somewhere
else, whatever. The point is that the HTTP server isn't the same entity
doing the application work. Developers who have been around the block
call this separation of responsibility, and it exists for a reason:
loosely coupled architectures are very easy to maintain.

And yet,
Node seems oblivious to this. Node has (and don't laugh, I am not
making this sh*t up) its own HTTP server, and that's what you're
supposed use to serve production traffic. Yeah, that example above when I
called http.createServer(), that's the preferred setup.

If you
search around for "node.js deployment", you find a bunch of people
putting Nginx in front of Node, and some people use a thing called
Fugue, which is another JavaScript HTTP server that forks a bunch of
processes to handle incoming requests, as if somebody maybe thought that
this "nonblocking" snake oil might have an issue with CPU-bound
performance.

If you're using Node, there's a 99% probability that
you are both the developer and the system administrator, because any
system administrator would have talked you out of using Node in the
first place. So you, the developer, must face the punishment of setting
up this HTTP proxying orgy if you want to put a real web server in front
of Node for things like serving statics, query rewriting, rate
limiting, load balancing, SSL, or any of the other futuristic things
that modern HTTP servers can do. That, and it's another layer of health
checks that your system will need.

Although, 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.
It's F*cking JavaScript

This is probably the worst thing any server-side framework can do: be written in JavaScript.

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

What is this I don't even...

tl;dr

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

然后有个叫Brady的进行了回应：

http://www.uberbrady.com/2011/10/nodejs-is-not-cancer-you-are-just-moron.html

Node.js is not a cancer, you are just a moron

My
tone is going to seem strangely even and un-ranty. This is because I am
doing everything I can to keep myself from completely exploding when I
read this bullsh*t that this moron is spewing. OK, that was a little
ranty, but the rest will read evenly. Maybe.

So one of my programming friends posts an article at http://teddziuba.com/2011/10/node-js-is-cancer.html and says, "Ah, here's what's wrong with Node.js!"

The
article is rather strongly written - "Node.js is Cancer", "node.js
nonsense", "Node.js is a tumor on the programming community",
"completely braindead", "Scalability disaster", etc.

He then shows a Fibonacci sequence and how it performs badly under node.

The
problem he has proposed is, fundamentally, CPU-bound. I wrote a version
of it in C and it did perform faster than it did in Node, but still,
the problem definitely took finite-time. My command-line Node.js version
calculated the answer in 8 seconds, the C version did it in 4. I was
rather impressed that Javascript (Node.js's V8 engine) was able to come
as close to C's performance in pure CPU-bound execution.

The
problem, and what the author perhaps misunderstands, is that this is not
the situation in which Node is an ideal solution. I use Node.js in
production for work - and I know of many other shops that do too. If the
problems you are dealing with are CPU-related, Node.js will not help
you. Node.js works well when your problems are I/O-related -e.g.,
reading something out of a database, running web servers, reading files,
writing files, writing to queues, reading from queues, reading from
other web services, aggregating several web services together, etc. The
reason that this solution has become so popular of late is because these
are the types of problems that are most common in web development
today. Thus, node.js becomes a helpful arrow in one's quiver with which
to solve these types of issues.

Considering that the article's
author seems to have some level of experience, I wonder if his choice of
skewed example was perhaps deliberate. He has other articles on his
blog about other event-loop libraries. His comment at the bottom -
"tl;dr - Node.js is an unpleasant software library and I will not use
it" - is possibly the real source of his anger. And - an irrefutable
point - if you don't like something, you don't want to use it, and he
obviously doesn't. That's fine.

Node is a tool; one of many - no
panacea. If you're dealing with problems of 'slow' services that need to
wait for various bits of I/O to complete in order to return a result -
it can be a very powerful and useful tool. If you're computing the
fortieth member of the fibonacci sequence recursively, it won't be.

The
sad fact is that the author's completely valid point - that Node.js
isn't a good tool for CPU-bound problems - is completely buried in his
bile. This is because he never states that, explicitly. Node.js has
other drawbacks as well - it's very easy to end up in
callback-spaghetti, it's very minimal, and it's very very very young.
The database integration libraries have some pretty serious immaturity
issues to work through; and I've had to code around a good deal of that.

It's
a tool that's good at particular things, and I will continue to use it
for those things. Those 'things' tend to be the bulk of what web
development and web services development actually are. So when I can
write a two hundred line program that can replace entire arrays of
servers and interconnected services with just one server; I am going to
do that, and I won't feel particularly braindead in doing so.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
整个来龙去脉是这样：
Ted Dziuba质疑Node.js的"非阻塞"的说法，举了一个求斐波那契数的例子，在一个求斐波那契数的方法里，花了5秒多的时间。而在调用这个方法的时候，线程是被阻塞了。
然后以此为事实，Ted进行了引申，严重的喷了Node.js和JavaScript。。。

然后Brady在他的Blog里进行了还击：
他
用自己的机器分别用JavaScript和C跑了下斐波那契数方法，分别耗时8秒和4秒，首先惊诧于JS引擎已接近了C。然后阐述了Node.js适合做
什么和不适合做什么。他觉得Node.js适合做的是IO相关的操作，而不适合严重依赖CPU的事情。攻击Node.js的人只是搞错了应用场景。 Node.js的“非阻塞”只是对于IO来说的，进行很耗CPU计算的操作还是会阻塞住线程，这个时候Node.js的单线程模式的不足就会暴露出来。
如何趋利避害呢？Brady已给出了提示，JavaScript语言非常适合回调方式的开发。所以，如果有耗时的方法，都要做成异步调用。