As a server-side technology, Node.js has it’s advantages and disadvantages. However, many developers who are accustomed to working with other server-side technologies will never even consider Node.js.
Sometimes, there are objective reasons for that. Other server-side technologies can, sometimes, achieve what Node.js cannot. However, there are also some popular misconceptions about Node.js that stop people from taking full advantage of it.
To make it easier for you to decide whether Node.js is something that you would ever consider, I have listed some of the most popular misconceptions about the technology. Some of these believes have a grain of truth in them, so I have also specified what to watch out for.
1. Node.js is fully interpreted
In server-side Node.js, just like on the client-side, all code is stored in human-readable text files. This made many developers conclude that the code in Node.js is also interpreted and is relatively slow as the result. However, this is not necessarily the case.
V8 engine of Node.js does pre-compile all the code into a set of instructions that CPU can easily understand. When you run your app, it runs a compiled version of it from the cache rather than reading your code from .js files directly.
Moreover, the optimizer of V8 engine is fairly aggressive. For example, if it detects that a particular variable only stores integer numbers with small values, it will convert it into a shorter version of an integer, so, 32 bit version will not be used when 16 bits are sufficient.
Having said that, the compilation process of V8 is not reliable and compilation is not guaranteed. This, however, usually only becomes a problem when your code is complicated. If this happens, your code will be run in interpreted manner. Therefore, Node.js is still not suitable for an app that needs to be both fast and complex.
In a scenario where you don’t own a server that hosts the app and don’t want to reveal your app logic, it is a problem. Therefore, Node.js is not suitable for an enterprise app that will run over client’s intranet, such as in defense-related system, internal accounting or an internal stock management system of a supermarket.
2. Node.js is slow
This follow up from the first point. When developers expect a programming language to be interpreted, they expect it to be slow. However, sometimes, even those developers who are aware of the V8 compiler insist that Node.js is slow.
Although it is a misconception, there is a grain of truth in it. On it’s own, V8 engine is lightning-fast. At least as fast as any other runtime running compiled code. However, some of the popular NPM package can, indeed, slow it down quite substantially. This is because some of them have a lot of unnecessary code.
Jordan Scales had a look inside some of these packages and wrote an article about it. It is quite an entertaining read and this particular code snippet from Babel made me chuckle:
So yes, Node.js is fast, but you need to be careful when you chose dependencies to add to your project.
3. Node.js is server-side only
When you build a Node.js app purely to be run on V8 engine, then the app will indeed be server-side only. However, you can also use V8 engine as a part of your IDE and leverage Node.js features to build a pure client-side app in minutes. I wrote about this topic in more detail in this article.
4. Node.js apps cannot be written in a type-safe way
5. Many NPM packages are unsafe
There is a grain of truth in this. Anyone can deploy packages into NPM repository, so there is no doubt that some of the packages in there have either been made with a malicious intent or are badly made and have security holes or serious bugs within them. However, the same applies to NuGet repository if you are a .NET developer or Maven repository if you are a Java developer.
Due diligence is necessary when you are working with third party packages regardless of what technology you specialize in. Before you choose to use any of those as a dependency in your project, you absolutely need to ensure that you can trust the package that you are about to download.
If you find a package that you have never heard of just by typing a certain keyword in the search box of your chosen repository and install it without any further thought, it will be your fault if the system brakes as the consequence, not the framework’s.
6. Node.js is single threaded
It is true to an extent, but not fully accurate. In Node.js, there is one thread per process. It is possible, however, to get your main process to spin up child processes, each of them running in its own thread.
However, the reason why some developers think that this is a significant issue is because they confuse single threaded with synchronous. The difference is explained here, but it can be summarized as follows.
Multiple threads don’t interact with each other. Each lives it’s own separate life. It is almost like running separate programs. Each thread, however, may be synchronous or asynchronous.
If a thread is synchronous, when a call is made to run a process that can potentially take some time, such as retrieval of data from a large database, everything stops until that process is finished. This is why synchronous threads are also referred to as “blocking “.
On an asynchronous thread, however, the only code that will be prevented from running will be the code that directly depends on the execution of the long-running process. However, if there is any code that doesn’t depend on it that can be run, it will be run on the same thread while the program is waiting for the process to return the result.
Because it is a single thread, if it has several logical paths, the runtime can only execute one of them at a time so it will alternates between them. But because CPUs are fast, you will not notice that. To a casual observer, different logical paths are executed at the same time.
As far as asynchronous execution goes, Node.js is actually great. After all, it is a framework that was built with asynchronous programming in mind and, as far as non-blocking logic goes, Node.js performs way better than some of the technologies that came before it.
7. Reputable companies don’t use Node.js in production
This can be clearly demonstrated not to be the case. Surprisingly, I have met enough developers who insist that Node.js is not a technology that major businesses would use in production. To alleviate any doubts, here is a list of some well-known companies that use Node.js, courtesy of To The News:
I am not a Node.js evangelist and I don’t deny that Node.js is not without its limitations.
Personally, I specialize in ASP.NET. However, I like experimenting with all kinds of technology and I believe that the decisions about the technology choice should be made based on facts, not popularized stereotypes.
This article has covered some of the popular misconceptions about Node.js. However, it provided very little information on how Node.js actually works.
If you aren’t very familiar with the technology, I hope that I have managed to persuade you of its great benefits. This website is one of the best places to learn the technology. It is very in-depth and gets updated on regular basis. I would certainly recommend you to check this out!