I have to say this before I get to my main point. I know that many people love Node.js and I don’t hold anything against them. This article is about why I personally don’t like Node.js based on my little experience with it. I won’t say I’ve used Node.js for very long, or that I’m experienced with it. I’ve tried it out on a few different occasions and this article explains my view of Node.js. You do not have to agree on these points.

Node.js

Node.js is basically JavaScript taken to the server environment. For years, JavaScript has ruled the client environment in web browsers. Everything funky happening on a web page is done by JavaScript. From dynamically loading data to animations, everything depended on JavaScript. Then one fine day, someone decided to take the JavaScript everyone (every web developer) loved so much and stick it into the server. Node.js is basically the Google V8 engine with some additional stuff to support server programming. Google V8 engine is the JavaScript engine present in Google Chrome. It soon found a growing user base and is now the favorite platform for developers.

JavaScript on the Client

The client environment is as unpredictable as it gets. With more than a few browsers and operating systems, it’s impossible to get any machine code to run on it; not to mention the security risks of running machine code. JavaScript was a God send to the browser world. With the wide spread support of JavaScript in the early days of the internet, a web developer could write JS and be assured that it would run on most environments. As of HTML5, JavaScript is the only official programming language for the browser. It’s all well and good for the browser because having a single programming language to work across every browser means less pain in the ass for a web developer. We can write a piece of code and expect it to run pretty much the same on every browser.

JavaScript on the Server

JavaScript is a necessity for the browser environment since it provides a way for us to forget all about the unpredictable and uncontrollable client software and code with peace of mind (well, what counts as peace of mind anyway). But move to the server and we have a whole lot of different programming languages for getting the job done. Actually, we can write the server software in C or assembly and the browser would not give a shit as long as the server talks HTTP. So why do we need a new language? Because, all the major languages have been around since the stone age and sticks to old standards. Bringing JavaScript to the server means giving the server something modern to work with. But, the question is, Is that really necessary? The old languages gets the job done good enough and people have a lot of experience with them to begin with. What’s the point of bringing in a new language if it’s meant to do the same thing as every other language that exists currently. There are a lot of arguments on that topic and I’m not going to go to that place here. The fact is, JavaScript exists on the server as Node.js and it’s going to stick around for some time since people are obsessed with how good (in their opinion) it is.

Node.js model

Node.js uses a single threaded “pump” to handle everything. Well, not literally everything since there are other threads that are responsible for IO, etc. Node.js has only one thread that executes server code, code written by us to do stuff. Now, this itself is not the problem, the problem is the baggage it carries with it. A single thread to do everything means we cannot do what we do in every other language without a second thought. Say for instance, we read from the database, do some stuff with the data and send some data to the browser and, optionally, store some data to the database. In a language like, say PHP, we can do that in one sequence like so:

$var = getData(“Some Query”);
$result = processData($var);
storeData($result);
sendData($result);

But, there is a problem with this. When we query the database, we spend some time outside of PHP. During the time the database is processing our query, PHP waits for the result. When the database returns the result, PHP resumes execution. This is all good in PHP since it is multi-threaded in Apache. But, in Node.js, the time spent waiting for the result from the database is wasted since Node is unable to do anything productive in that time, and having only one thread means that a whole lot of stuff may get blocked till the database is done processing. So, in Node.js, we use callbacks for every IO operation. The callback is called when the IO is done and we have a result to work with. So, the same in Node.js, we need to write the same thing like so:

getData(“Some Query”, function(var) {
result = processData();
storeData(result, function() {
sendData(result);
});
});

You may think, this isn’t too much of a problem and you are right, in this case. The problem begins to surface when we need to do a whole lot of IO. Soon we’re drowning inside callbacks, this is known as “callback hell”. Now, every half decent Node programmer will yell, “there’s modules like ‘async’ help with that’. But, that’s not how a language should be. I shouldn’t have to install modules to be able to write decent code. And there’s another problem with such modules that I don’t want in my code. For instance, a sample code using ‘async’ module may look like so:

async.series([
function(callback) {
// some stuff
callback(err, result);
},
function(callback) {
// some stuff
callback(err, result);
}]);

The main problem with this code is passing variables from one function to another. If I’m reading data from multiple sources, I need to explicitly pass the data to the next callback. So, in every function, I need to accept the data from the previous function and pass it on to the next function. This here just created net positive work for me to do and a pitfall for me to fall into. A language or platform should try to reduce the work that I need to do to get it to work. I should not create net positive work or pitfalls for me.

My Conclusion

Bringing JavaScript into the server is all well and good. I don’t have a particular problem with using JavaScript on the server. However, I do have a problem with the extra work that I have to do in order to get the same result as a different language or platform. Also, in Node.js, I have to check for error after every IO operation; this creates a whole lot of work and traps for me as a developer.

I’ve only worked with Node.js very little and so, I don’t have a whole lot of experience with it. As such, I may not be aware of solutions to the problems I mentioned. But, I’ve decided to steer clear of Node.js wherever possible. It’s a personal decision and I’m sticking to it for the time being.