2 June, 2020
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!
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 14 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.
🤔 Are you a tech manager looking for experienced Node.js developers? We’re here to extend your development team – in weeks, not months. Schedule free software consultations and find out more
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!
ES modules support
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 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!
Interested in developing microservices? 🤔 Make sure to check out our State of Microservices 2020 report – based on opinions of 650+ microservice experts!
JS and private variables
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
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.
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!
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 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?
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.
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!
See also: Swoole – Is it Node in PHP?
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!
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.
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!
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.