Non-Blocking thread execution = massive speed gains

Perhaps it’s greatest feature is its least understood by those who are considering it and rookies. Non blocking means that whilst we are waiting for for a response for something outside of our execution chain eg loading some data, reading from a database or polling a remote service, we continue executing the next tasks in the stack. This concept is revolutionary and make NodeJS extremely fast and efficient. When it comes to code in loops this is particularly relevant. For example if we have to load 50 chunks of data and each one takes 50ms, in traditional linear execution that would be 50x50 = 2.5 seconds. NodeJS will fire off all of those requests straight away so all those requests go out in parallel and are handled when they return. Typically making 50 requests might take less than 1ms so are time to fetch 50 requests might be <51ms.

Multi-threaded

One of the most common complaints by people who do not understand node JS is that it is single threaded and if you have an core CPU it will only run on one core. Nothing could be further from the truth, and is another case of “fake news”. In tandem with its non blocking architecture multithreaded apps are also highly efficient.

Node.js is non-blocking which means that all functions ( callbacks ) are delegated to the event loop and they are ( or can be ) executed by different threads. That is handled by Node.js run-time. Node.js does support forking multiple processes ( which are executed on different cores ). It is important to know that state is not shared between master and forked process. We can pass messages to forked process ( which is different script ) and to master process from forked process with function send.

Cross platform

Move aside Java, NodeJS is not only cross platform, but when developed with the correct structure can be packaged into an executable containing all its own dependencies.

Build vs Compile = Significantly Faster Development Environment

If you are a developer who likes to check their code as they go then being able to see your code running in under a second vs 30 seconds + for .net and java equivalent scale systems is a game changer in terms of speed of delivery.

Object Oriented

A huge complaint against NodeJS was down to its JavaScript heritage, which frequently involved lots of procedural spaghetti code. Frameworks like CoffeeScript and TypeScript solved these issues, but came as a bolt on for those who seriously cared about coding standards. Now with the release and general adoption of ES6, Classes are built into the framework and the code looks syntactically similar to C# , Java and SWIFT.

Synchronous Code Execution

Non blocking code execution is conceptually more difficult to code than code that runs in a straight line, because we have blocks of code hanging around waiting for asynchronous events to return. Whilst those blocks are waiting to execute maybe some of our variables have changed values eg for our code that fetches 50 pieces of data the index counter will count from 1 to 50. In straight line coding the counter would be at 1 when the first piece of data returns and 10 when the 10th piece of data returns. In our non blocking environment we fired all the calls off as quickly as we could rather than waiting for one to finish before we fired the next. THAT IS A HUGE GOTCHA FOR NOOBS because the counter is sitting at 50 for every returning piece of data (since it got to 50 at light speed). Most NodeJS noobs fail at this point because they do not understand why their code has failed.

Over 600,000 free Open Source packages on NPM

The Node community is enormous and the number of permissive open source projects available to help you save time is mind boggling. These libraries range from simple helpers and charts to full blown frameworks.

Create both SASS, Service and Desktop Platforms

Whilst originally a cloud web solution, there was pretty rapidly a demand for NodeJS to be usable in desktop applications. The ElectronJS project bridges this gap, amd many common apps are based on electron including Slack, Visual Studio Code, Discord, Skype and many more.

Being Based on Javascript Means Frontend and Backend Developers use the Same Language

Back in the last millenium, backend developers earned many times more than frontend developers and frequently would avoid frontend code in the same way one might avoid a steamy dog mess on the pavement. However the world moved on and people started to realise that rather than slowing the experience down by preparing everything on the backend server it was possible to use the backend server to send the data and leverage the power of HTML5 browser rendering. Having the backend and frontend skillsets merged,buts the brightest minds working together instead of pulling in different directions.

Sockets and Two Way Data Binding

Most of the web is based on a system of request and response. i.e. I ask for a page and the server sends me a page. The early chat apps used to used something called a poll, where they simply asked every second - “are there any new messages”. This approach clearly sucked, and sockets stepped into the gap. Sockets allows a server to broadcast messages to all clients connected a specific group. Not only that but sockets allow on client to broadcast (via the server) to a whole group. Great for chat groups, and even better for data binding. If one user changes some data, all the other users can be updated in milliseconds. Whilst other languages do have socket libraries, NodeJS has an advantage because of its event driven non blocking architecture, which makes it ideally suited to handle sockets. NodeJS was the first to do it well and still does it better than any other framework.