I found this blog post and thought how refreshing it was to see someone present a different point of view on
Node.js. All you really hear is how wonderful it is and Ted Dziuba does a great job at presenting a negitive view of the ever increasing popular
Node.js framework.
If there’s one thing web developers love, it’s knowing better than conventional

wisdom, but conventional wisdom is conventional for a reason:
that shit 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 fucking 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.
Continue… at
by Ted Dziuba