Back to all blogposts

New Node.js 14-15 features will disrupt AI, IoT & more. Node latest version report

Adam Polak

Adam Polak

Head of Node.js Team

Since Node is primarily known and loved for its speed and simplicity, new Node.js features are not the main selling point of this popular JavaScript runtime. But the latest Node.js features revealed in Node 14-15 are really exciting. Some of them have been built on previously introduced ideas such as threads. But there are also a lot of new experimental Node.js features. The latest Node version, Node 15, as an odd-numbered version, is not going to become LTS. But it does introduce many new concepts that may really change Node for good. Let’s take a look at Node version 14-15 (long term support version of Node js and current release – version 15)

With Node 14 going LTS in October, we also started thinking about what the future is going to bring us. And the future seems bright!

Every odd version of Node update gets end of life quicker, but at the same time is kind of a sandbox for future experiments and this year we’ve got a few interesting changes in Node 15.

This article has been updated to reflect the latest changes added in Node.js 15. What you can find here is a thorough overview features from the latest version of Node (14-15).

NPM 7 – what’s new?

With Node 15 , we’re getting npm 7.

This is yet another big step for the whole community, with some very interesting features added.

Workspaces are one of the most interesting ones. Yep, npm is getting what yarn has been known for. If you’re using lerna or was thinking about monorepo for your packages, this is what you were looking for. Read more about this on the npm repository page.

The second one is also somehow related to yarn. With npm 7, the yarn.lock file is no longer ignored. Npm is going to read yarn lock for package metadata and resolution guidance and then create its own package-lock.json.

Package-lock has also changed. With npm 7, we are introduced to a completely new format of that file. The new version (V2) contains everything that is necessary for deterministically reproducible builds. This is the difference between npm and yarn. Yarn deterministic builds are based on a yarn.lock and a version of yarn. So if we used a different version, then we’re going to get a different set of packages.

For npm, this is going to be consistent even between different versions.

Unhandled rejections change

For typical synchronous flow, Node.js closes its process as soon as an error is thrown. However, it’s a different story when it comes to asynchronous operations.

For years, we had to add two important event handlers to secure our apps – uncaughtException and unhandledRejection.

Node 15 introduces a huge update on how unhandled promise rejections are handled. The default mode was changed from warn to throw.

In Node 14, an unhandled rejection printed a warning to the console. In Node 15, those will be handled as uncaught exceptions and will cause your app to exit.

This is a good change!

V8 new version

As usual, a new Node is shipped with the new version of V8. This time, we’re getting four new features:

The first one is support for Promise.any. This is something similar to Promise.race. However, the resolution is a bit different. Promise.any is resolved as soon as at least one promise is fulfilled and rejected only when all promises are rejected – learn more.

The next one is related to error aggregation. With V8 8.6, we’re getting a new error type – AggregateError. It takes an array of errors. A good example is an error from Promise.any. Instead of throwing an array of errors, it throws a single one containing an array of errors.

The third one is a support for String.prototype.replaceAll. As the name says, it is about replacing all occurrences of a specific string or pattern. For example:

The last one are new logical operators – &&=, ||=, ??=. It is easier to see them in action than to explain it, so let’s see the code:

It all comes on top of the changes and improvements introduced back in Node 14 with V8 8.1:

  • Access to the private field.
  • Awaits should work much faster, as should JS parsing.
  • Our apps should load quicker and asyncs should be much easier to debug, because we’re finally getting stack traces for them.
  • The heap size is getting changed. Until now, it was either 700MB (for 32bit systems) or 1400MB (for 64bit). With new changes, it’s based on the available memory!

With the latest Node version 14, we’re getting access to the newest V8. This means that we’re getting some popular features of the JavaScript engine.

If you’re using TypeScript, you probably work with nullish coalescing and optional chaining. Both of those are natively starting with Node 14.

We’re also getting a few updates to Intl. The first one is support for Intl.DisplayNames and the second one is support for calendar and numberingSystem for Intl.DateTimeFormat.

New experimental features

Node 15 also brings some new experimental features.

The first one is a support for QUIC – a new UDP-based transport protocol that is used in HTTP/3. You can find more information about this here.

If you want to play with it, remember to run node with –experimental-quic.

The second one is AbortController. The main use case is signalling the promise cancellation. Right now the implementation is experimental, but still, we’re waiting for more!

Node + Web Assembly = <3

Web Assembly is slowly gaining in popularity. More and more Node modules are experimenting with this language and so is Node itself! With the Node 15 release, we gain access to the experimental Web Assembly System Interface – WASI.

The main idea behind this is to provide us with an easier way to access the underlying operating system. I’m really looking forward to seeing more Web Assembly in Node.

Stable Diagnostic Reports

In Node 12, we’ve got a new experimental feature called Diagnostic Reports. By using it, we could easily get a report that contains information about the current system. What’s more, we can generate it not only on demand but also after a certain event.

If you have any production running a Node app, then this is something you should be checking out.

Threads are almost stable!

With the last LTS we’ve got access to threads. Of course, it was an experimental feature and required a special flag called –experimental-worker for it to work.

With Node 12 it’s still experimental, but won’t require a flag anymore. We are getting closer to a stable version!

Need support with top-class Node.js programming?

🚏 Find out what you can achieve with Poland’s biggest Node team that builds performance-driven apps for millions of users.

ES modules support

Let’s face it, ES modules are currently the way to go in JavaScript development. We are using it in our frontend apps. We are using it on our desktop or even mobile apps. And yet, in case of Node we were stuck with common.js modules.

Of course, we could use Babel or Typescript, but since Node.js is a backend technology, the only thing we should care about is the version of the Node installation on the server. We don’t need to care about multiple different browsers and support for them, so what’s the point of installing a tool that was made precisely with that in mind (Babel/Webpack etc.)?

With Node 10, we could finally play a little with ES modules (current LTS has experimental implementation for modules), but it required us to use special file extension – .mjs (module javascript).

With Node 12, it’s getting a little bit easier to work with. Much like it is with web apps, we get a special property type called that will define if code should be treated like common.js or es module.

The only thing you need to do to treat all your files as a module is to add the property type with the value module to your package.json.

From now on, if this package.json is the closest to our .js file, it will be treated like a module. No more mjs (we can still use it if we want to)!

So, what if we wanted to use some common.js code?

As long as the closest package.json does not contain a module type property, it will be treated like common.js code.

What’s more, we are getting new an extension called cjs – a common.js file.

Every mjs file is treated as a module and every cjs as a common.js file.

If you didn’t have a chance to try it out, now is the time!

💡 Read more

JS and private variables

When it comes to JavaScript, we have always struggled to protect some data in our classes/functions from the outside.

JS is famous for its monkey patching, meaning we could always somehow access almost everything.

We tried with closures, symbols and more to simulate private-like variables. Node 12 ships with the new V8 and so we’ve got access to one cool feature – private properties in the class.

I’m sure you all remember the old approach to privates in Node:

We all know it’s not really a private – we are still able to access it anyway, but most of IDEs treated it like a private field and most of Node devs knew about this convention. Finally, we can all forget about it.

Can you see the difference? Yes, we use # character to tell Node that this variable is private and we want it to be accessible only from the inside of this class.

Try to access it directly, you’ll get an error that this variable does not exists.

Sadly some IDE do not recognize them as proper variables yet.

Flat and flatMap

With Node 12, we’re getting access to new JavaScript features.

First of all, we’re getting access to new array methods – flat and flatMap. The first one is similar to Lodash’s flattenDepth method.

If we pass a nested arrays to it, we will get a flatten array as a result.

As you can see, it also has a special parameter – depth. By using it, you can decide how many levels down you want to flatten.

The second one – flatMap works just like map, followed by flat 🙂

Optional catch binding

Another new feature is optional catch binding. Until now we always had to define an error variable for try catch.

With Node 12 we can’t skip the entire catch clause, but we can skip the variable at least.


Another new JavaScript feature is the Object.fromEntries method. It’s main usage is to create an object either from Map or from a key/value array.

The new Node.js is all about threads!

If there is one thing we can all agree on, it’s that every programming language has its pros and cons. Most popular technologies have found their own niche in the world of technology. Node.js is no exception.

We’ve been told for years that Node.js is good for API gateways and real-time dashboards (e.g. with websockets). As a matter of fact, its design itself forced us to depend on the microservice architecture to overcome some of its common obstacles.

At the end of the day, we knew that Node.js was simply not meant for time-consuming, CPU-heavy computation or blocking operations due to its single-threaded design. This is the nature of the event loop itself.

If we block the loop with a complex synchronous operation, it won’t be able to do anything until it’s done. That’s the very reason we use async so heavily or move time-consuming logic to a separate microservice.

This workaround may no longer be necessary thanks to new Node.js features that debuted in its 10 version. The tool that will make the difference are worker threads. Finally, Node.js will be able to excel in fields where normally we would use a different language.

A good example could be AI, machine learning or big data processing. Previously, all of those required CPU-heavy computation, which left us no choice, but to build another service or pick a better-suited language. No more.

Threads!? But how?

This new Node.js feature is still experimental – it’s not meant to be used in a production environment just yet. Still, we are free to play with it. So where do we start?

Starting from Node 12+ we no longer need to use special feature flag –experimental-worker. Workers are on by default!

node index.js

Now we can take full advantage of the worker_threads module. Let’s start with a simple HTTP server with two methods:

  • GET /hello (returning JSON object with “Hello World” message),
  • GET /compute (loading a big JSON file multiple times using a synchronous method).

The results are easy to predict. When GET /compute and /hello are called simultaneously, we have to wait for the compute path to finish before we can get a response from our hello path. The Event loop is blocked until file loading is done.

Let’s fix it with threads!

As you can see, the syntax is very similar to what we know from Node.js scaling with Cluster. But the interesting part begins here.

Try to call both paths at the same time. Noticed something? Indeed, the event loop is no longer blocked so we can call /hello during file loading.

Now, this is something we have all been waiting for! All that’s left is to wait for a stable API.

Want even more new Node.js features? Here is an N-API for building C/C++ modules!

The raw speed of Node.js is one of the reason we choose this technology. Worker threads are the next step to improve it. But is it really enough?

Node.js is a C-based technology. Naturally, we use JavaScript as a main programming language. But what if we could use C for more complex computation?

Node.js 10 gives us a stable N-API. It’s a standardized API for native modules, making it possible to build modules in C/C++ or even Rust. Sounds cool, doesn’t it?

Building native Node.js modules in C/C++ has just got way easier

A very simple native module can look like this:

If you have a basic knowledge of C++, it’s not too hard to write a custom module. The only thing you need to remember is to convert C++ types to Node.js at the end of your module.

Next thing we need is binding:

This simple configuration allows us to build *.cpp files, so we can later use them in Node.js apps.

Before we can make use of it in our JavaScript code, we have to build it and configure our package.json to look for gypfile (binding file).

Once the module is good to go, we can use the node-gyp rebuild command to build and then require it in our code. Just like any popular module we use!

Together with worker threads, N-API gives us a pretty good set of tools to build high-performance apps. Forget APIs or dashboards – even complex data processing or machine learning systems are far from impossible. Awesome!

Full support for HTTP/2 in Node.js? Sure, why not!

We’re able to compute faster. We’re able to compute in parallel. So how about assets and pages serving?

For years, we were stuck with the good old http module and HTTP/1.1. As more and more assets are being served by our servers, we increasingly struggle with loading times. Every browser has a maximum number of simultaneous persistent connections per server/proxy, especially for HTTP/1.1. With HTTP/2 support, we can finally kiss this problem goodbye.

So where do we start? Do you remember this basic Node.js server example from every tutorial on web ever? Yep, this one:

With Node.js 10, we get a new http2 module allowing us to use HTTP/2.0! Finally!

Full HTTP/2 support in Node.js 10 is what we have all been waiting for

With these new features, the future of Node.js is bright

The new Node.js features bring fresh air to our tech ecosystem. They open up completely new possibilities for Node.js. Have you ever imagined that this technology could one day be used for image processing or data science? Neither have I.

Latest Node js version gives us even more long-awaited features such as support for es modules (still experimental, though) or changes to fs methods, which finally use promises rather than callbacks.

Still wonder if you should update Node version of yours? Watch this short video on Node version update in 2020.

As you can see from the chart below, the popularity of Node.js seems to have peaked in early 2017, after years and years of growth. It’s not really a sign of slowdown, but rather of maturation of this technology. Latest Node js version maintains the trend.

Popularity of Node.js over time chart, peaked in 2017

However, I can definitely see how all of these new improvements, as well as the growing popularity of Node.js blockchain apps (based on the truffle.js framework), may give Node.js a further boost so that it can blossom again – in new types of projects, roles and circumstances.

With the release of Node.js 14, the future is looking brighter and brighter for Node.js development. You can definitely go for Node upgrade without hesitation! And what will the future release bring? We’re definitely going to analyze it for you as soon as it is here!

💡 Read more

Want to develop powerful web applications? Node.js is a powerful open source platform perfect for working with high-performance applications. All the minor and major (LTS) releases bring new exciting changes that make it difficult to resist updating Node.js!

As you can guess from reading this article, we’ve got a pretty strong Node.js team here at The Software House. If you want us to help you benefit fully from using Node, you’re more than welcome to contact us! You can contact our experts now and those initial consultations will be completely free.

You may also like

What would you like to do?

    This site is protected by reCAPTCHA and the Google
    Privacy Policy and Terms of Service apply.

    They are more than just a software company. They are the partner who will help you achieve what you want to achieve.

    Nick Gold

    Managing Director at Speakers Corner


    Thank you for your inquiry!

    We'll be back to you shortly to discuss your needs in more detail.