There is no doubt it’s one of the most fast-growing programing languages in the last few years, stealing some (or a lot) of the ‘thunder’ from Ruby On Rails, which seemed to be growing into the standard language for web development.

This rise in popularity is due to several reasons, which could be considered as the ‘Good Parts’, including: development of non blocking applications by default, an incredible dependency manager and specially the ability to take advantage of the JavaScript knowledge, that almost every programmer knows about.

In that respect, those developers who come from a synchronous programming language (actually the majority) like PHP or Ruby, will find themselves writing more efficient applications without even realising, thanks to the language nature. However, before starting a new project with Node, you should also be aware of its Bad Parts.

Single Thread

Node runs in a single thread. This means that if you deploy your application in a 8-core server you will be wasting your money because most of the CPU resources will not be used.

Consequently, it can’t run parallel operations because it will not be able to run two actions at the same time. To try to mitigate this problem, Node uses an Event Loop, so the thread will never be (or shouldn’t be) blocked, which allows to make the most of the thread in terms of performance.

A workaround to use the full capacity of our servers, it’s to spawn several Node processes, that way there will be multiple instances running in different threads.

Although we can use the full capacity of the machine this way, the ability to manage threads and optimize your code with parallel tasks is still missing.

Not distributed by default

Sooner or later, all applications need to grow in order to have a good time response. That usually means distributing the load through different machines.

Unlike other technologies like Erlang or Akka, which implement the Actor Model, Node doesn’t allow each component of the system to be run in the same machine or in a remote process in a transparent fashion, that is why you will have to change your application structure to make it distributed.

In order to distribute a module of your application, you will have to completely uncouple it and make it run through sending events. Node hasn’t got a built-in implementation to send messages between remote processes, so you will have to use a backend service like Redis or RabbitMQ.

Newborn

One of the biggest criticisms by many developers who tried Node is its immaturity, even saying that it’s a language for playing, not for creating “real” applications.

In my opinion, I think the success of Node has overflowed any acceptation expectation, therefore it couldn’t grow at the suitable velocity required by the community.

Nowadays things have changed a lot. There already exists stable drivers to use with the majority of the services in your backend, frameworks to organize and abstract your code and a lot of utility libraries to make your life easier.

Even so, you must take into account that in the Node package repository, anyone can publish their libraries, so you have to be careful when choosing a library to add to your project as dependency, because there are many that are unattended or even obsolete. Obviously, you must always choose those which are supported by the official corporation or community.

Missed Promises

Promises give you an abstraction that lets you model problems at a higher level, and leave more work to your tools — James Coglan

James Coglan wrote a brilliant article explaining why using callbacks keep us away from the problem resolution, since we have to program the program flow in an imperative way.

In addition, using callbacks to control the flow, brings up a new problem known as “callback hell”.

To avoid this, there are libraries like async, which allow you to control the flow better. However this is not a replacement for the use of promises because they allow you to write asynchronous code in a similar way to synchronous code and abstract us from worrying about the flow and focus on resolving the problem.

As James says in his post: “Node’s biggest missed opportunity”.

Conclusion

I have shown you some of what I consider as bad parts of Node, but that doesn’t mean that it’s a bad technology, they are only a bunch of things to bear in mind when deciding if you should use it in your project.

So for example, if a key strength of your application is distribution through hundred of machines, with supervision and auto recovery to errors, you have to know that with Node you won’t have it by default and you will have to look for solutions.

On the other hand, the development velocity with Node is very high, which makes it a very suitable platform to build functional prototypes. Once you have your prototype working and the product validated, then you can decide whether to migrate to another more suitable technology or to continue with Node, taking into account The Bad Parts.