Magic and Myths of Node.JS
In May 2020, Node.JS turned 11 years old.
Since its inception, this programming language has brought the magic of asynchrony into JavaScript and gave us the ability to create applications with an unprecedented speed of request processing. And over all these years Node.JS has overgrown with many myths about its reliability and functionality.
I have known Node.JS since its first appearance, and we have been united by close cooperation for years. That is why I decided to write this article and share my own point of view regarding the magic and myths of Node.JS.
Magic of Node.JS
Back in 2009, then unknown Ryan Dahl created Node.JS and gave the IT community a completely new way to build scalable network servers — simple, low-cost and fast.
Dahl created magic: he turned JavaScript from a highly-specialized into a general-purpose language. Node.js added the ability for JavaScript to interact with input/output devices through its API to connect other external libraries written in different languages, providing calls to them from JavaScript code.
However, the most important Dahl’s trick was event-oriented and asynchronous (or reactive) programming with non-blocking I/O.
In the world before Node.JS, we worked with a multi-threaded server which used the thread-per-request model: the server can process several requests at the same time, but only one request per thread. What does it mean? Supposing, to process with N requests, the server needs N threads. If the server receives N + 1 requests, then it must wait until one of the threads becomes available.
Unlike a multi-threaded server, Node.js uses non-blocking I/O operations. It means that the mainstream will not be blocked by I/O operations, and the server will continue to serve requests, regardless of their number. It’s a kind of magic, isn’t it?
Triumph of Node.JS
Triumph came to Node JS a couple of years after its first release.
Worldwide technology pioneers such as LinkedIn, Uber and PayPal were among the first companies which decided to switch to Node.JS.
Their results were exceptional: after updating the mobile application through Node.JS, LinkedIn and Uber reported the exponential increase in the effectiveness of communications with partners and customers.
And here is the PayPal’s performance test comparison between Java and Node.JS below, which speaks for itself:
A 200ms reduction in page response time and a 90% increase in the number of requests that an application can execute per second — that is truly impressive.
Myths of Node.JS
Now then, let’s break free from the magical charm and take a look at another side of Node.JS.
Having gone through the triumph stage, over the next few years Node.JS did not developed so actively, and one can say it has been in decline.
That is why over the past 5 years Node.JS was overgrown with myths that prevent many developers from appreciating its current merits now.
Well, I would like to dispel the main ones.
Myth #1. Node.JS is too primitive.
It is true, if you have not followed its updates since 2014.
As I was saying, having gotten all the best from JS at the start, Node.JS really slowed down in 2012–2014. “Zero” versions of this period did not please us with stability and functionality.
In 2015 the situation changed dramatically: Node.JS released version 4.0 and forged ahead — this version not only supported all previously released JS libraries and frameworks, but also included all the latest technologies, which were developed on the io.js fork.
Since 2015 and until now, we have seen a rapid improvement of Node.JS. The ability to create multithreaded parallel applications, implement parallel programming primitives and work with shared memory — this is a small part of what Node.JS gives us now.
in addition, in April 2020 a new version of Node JS was released, and we still have to evaluate its merits.
I hope, these arguments are enough to move Node JS from “primitive” to “worth learning” category.
Myth #2. Node.JS is not suitable for developing applications with the highest requirements for accuracy and uninterrupted operation.
I associate this myth with the fact that initially Node.JS did not have strict code standards. Certainly, if we do not have standards, it is pointless to talk about the reliability of Node.JS for these applications.
Should we be convinced that Node.JS is not suitable for serious projects after all? No, we shouldn’t.
All we need to do is to choose the right standards and set up their compliance check.
Working with Node.JS on projects of Enterprise level we rely on solid code style standards, for example Airbnb provides a good JavaScript Style Guide. In order to make sure that the code meets the necessary requirements, we use TS Lint / ES Lint.
The check runs before the committing phase, and all possible errors are corrected at the “zero” stage.
And, of course, we do not forget about the good Unit and Integration test coverage at the final stages.
This approach allows us to create applications with the highest requirements for accuracy and uninterrupted operation.
Let’s consider that another myth is destroyed.
Myth #3. Node.JS has a type-safety problem.
I heard this phrase from a few developers as the reason why they do not use Node.JS.
Here again, the question is how much you know about Node.JS and what technology stack you have in general.
As for our team, we completely solved the type-safety problem using TypeScript config and setting automatic code checks.
We have used this approach on many projects, and now I can say with confidence: with good automated code quality checks, the TypeScript guarantees the necessary level of a type safety.
Instead of conclusion: as you already noticed, I like Node.JS. I am impressed by the improvement of this programming language, and I see its great potential in the future.
I am also convinced that Node.JS has a great deal of advantages in server-side development of solutions with different levels of complexity right now. It is not inferior to static languages, and in some cases even surpasses them, that it why it is definitely worth paying attention to.
