Why the Hell Would You Use Node.js
Node.js Foundation

I see this arguing often appear and I think it is focussing on the wrong points. In every domain mentioned both Node and the competition have strong reasons of why to use and those reasons transform over time and expertise.

I.e. take the performance argument: a common assumption is:

Go > Java > Node > Python > Rails > PHP

Even for computational programming is only true for very basic programs. You can implement logic in C and bind it to JavaScript which allows you to write very quick implementations in Node.js. Python, particularly with CPython can be incredibly fast and the performance of PHP strongly depends on the VM.

This holds true for parallel processing or Node.js’s async loop: In every programming languages you have tools that easily destroy every advantage gained through other features. A good example for this might be transactions in the DB access layer: Applied wrong it can crush any memory advantage.

But even if you put this aside, the CPU/Memory and I/O throughput of all these systems are limited. Once you need to scale beyond the hardware , factors such as compose-ability and distributability become a much bigger question. Which means this whole discussion is just about shift of the point-in-time when you need to deal with those complexities. A particular paint point is the Chat example: Depending on the Scale and latency of an Application, you will likely use Erlang rather than Node.js for something like an international MMORPG.


In my opinion we can do better. The approach I usually take to explain the advantages of Node.js uses different angles. I try to focus on the points where Node.js can objectively be set apart from other languages.

Micro tasks — Zeit.co/now, AWS Lambda, Google Cloud Functions and Azure Functions all have Node.js as first class citizen. And not for no reason: Node.js functions are good to sandbox and execute in a context. These stacks allow you to quickly modularize your application and both scale and distribute them effectively and globally, other languages are often missing and even with Docker are by far more painfully. (Docker is not easy)

Compose-ability — Node.js has very simple, well documented and sufficiently well performing I/O capabilities for a wide variety of protocols! The Linux process I/O is quick, tcp and udp are well implemented and http is at its core. It also has some very well performing websocket implementations. This means that if you ever run into an issue where Node.js is not comfortable or doesn’t fit: it can quickly become communicate with any other service. The I/O in many other languages (like PHP or Java) can become significantly more bothersome.

Education — if you are familiar with JavaScript, Node.js comes with a good set of familiarity. It also comes with an reduced cost in tooling and education. Many tools, the IDE etc, that you use for the server can be used on the client and vice-versa (Moment.js is a nice example). While this is certainly not as strong one might think, it should not be ignored as it might mean a lot: Using different IDE’s might mean big differences in the engineers efficiency for example.

Hiring & Onboarding— This does not need to be language specific but somehow has become a feature of the Node.js community. The setup process of most projects in the Node eco-system is a breeze. The strong reliance on package scripts and the standards of how a system setup makes it easy to enter a new project. This, combined with the popularity of JavaScript makes hiring and on-boarding to Node.js a lot easier.

Time to Market — Electron is by now known as being very memory intensive and not always tests great with users but it allows to extremely quickly build applications which makes it very attractive if your solution is time-sensitive. This holds true for both almost every problem domain: Web Services, IoT applications, Desktop applications most of those can be built in a very short time compared to other technologies.

Visually complex web applications — It has been mentioned with the various dashboards above. But this is imho. much more general: Node.js has very good libraries like Gulp, Sass or Browserify to deal with the complexity of CSS, JavaScript and HTML. As soon as you exceed the basic levels you will have to use Node.js at some point, even if its just in combination with another system. Other platforms are simply not as well developed in that regard.


Downsides on the other hand should be mentioned as well and I feel the following sections are much clearer cut than the examples mentioned above.

A/V Processing — Even though there are bindings to OpenCV or GraphicsMagick: handling image, audio or video data with Node.js quickly becomes problematic. It is probably still more comfortable than PHP but you quickly run into limitations of the given libraries. They are simply not as well as their C, Go or Python counterparts. This particularly holds true if you want to render complex graphs or videos in a context other than HTML.

Scientific Programming— SciPi (Python), MathLab and Rust have made names for themselves in the science community because they are fast and offer far more than is currently available on NPM. Everything but some specific domains are better covered by alternatives.

Embedded Programming — Other than for prototyping, the VM simply is at the moment not suited for embedded programming. Garbage collection, startup speed and memory consumption quickly surpass anything available in a low-spec environment.

CMS — The CMS systems available in other programming languages (Particularly PHP) are in many cases far further developed, have a broader community than anything I have seen in Node.js so far and allow for quicker setup of custom systems.

Complex custom UIs — This is a similar concern with JavaScript in general: If you have user interfaces that need to be special (like Medical applications, Photo Manipulation tools, Architect software or complex games) then you should definitely look to work with different tools and once you do that the JavaScript advantage dwindles. This holds true both for the Desktop and for Mobile UIs!

Static & strict systems —Work that is strongly tied to Legislation that should not (or rarely) be updated in order to deal with real-life restrictions is not really suited for JavaScript. You would need to write a lot the tests that could be easily covered with static types in another system. Static systems also come with general efficiency benefits that are difficult to harvest with Node.js and generally require more effort. (See: Protocol Buffers as an example for the advantage of static typing)


Last but not least I am missing a section that is easily overlooked when recommending Node.js, namely: Where Node.js is not a problem! This is important because the years have resulted in prejudice against the platform.

Security—Node.js has fast and varied ways to test anything. There are public security companies and relatively good policies in place. The ssl implementation are always up-to-date. The tools available encourage good security settings. The Database layers are generally written after SQL injections have become general knowledge so they usually don’t have the same issues as older counter-parts. Generally: if you run into a security issue then it is likely for a reason that wouldn’t be prevented by other platforms as well and usually they are fixed with much less effort due to the excellent capabilities of NPM.

Longevity — A good majority of NPM packages support Node.js 0.12 which has been published 2 years ago. But more importantly: Semver has been adopted in many Node.js communities and they allow both upgrading and maintaining projects without much pain. It should be pointed out that many of the libraries found on NPM come with git links that you can clone if an error should occur — something not necessarily true for all other languages. And while it is true that the eco-system changes quickly: The Node.js core API has stayed mostly stable.


I feel like this could be more usable than the explanation above, do you disagree?

Like what you read? Give Martin Heidegger a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.