Understanding the Latest Node.js Versions

As with all new Node.js versions, the April 2021 release of Version 16 brought a host of changes to the server-side runtime environment. Node v16 added a new integrated package manager, several developer wish-list features, and support for a new generation of microprocessors. With Node v17’s release in October 2021, Node v16 moves to Long-Term Stable status for 30 months. LTS status means a Node version is suitable for commercial software, and that’s a persuasive reason to examine what’s new in Node v16.

ARMed and Ready: Apple Silicon Support

In November 2020, Apple introduced a trio of Mac computers with ARM 16-core M1 processors. The M1 uses the reduced instruction set architecture, and the new chips have proven to run significantly faster and cooler than the Intel processors Apple has employed since 2006. To maintain compatibility with applications written for Intel chips, Apple supplies the Rosetta 2 emulator for M1 Macs.

Node v16 brings native support of Apple’s M-series chips for developers coding in the Mac ecosystem. A single downloadable package selectively installs optimized Node v16 builds for both Intel and M-series architectures. Early trials indicate the programmers using Node v16 on an M-series Mac will see a noticeable productivity boost, with build times reduced by as much as 40%.

Intel or M-series, Mac-based developers will need Apple’s XCode 11 Command Line Tools to work with Node v16. Windows developers will need Visual Studio 2019 or higher, and Linux coders must use GCC 8.3 or greater. Along with Apple M-series and Intel support, Node v16 also ships PowerPC binaries.

Promises, Promises: New APIs

Promises are Javascript objects that streamline the handling of asynchronous tasks, operations that run simultaneously. Drilling down a bit more, promises are an efficient way to guarantee the completion of tasks in a predictable and reliable order. Better still, promise objects make for readable and easy-to-maintain code. Node.js v16 implements promise objects in a trio of application programming interfaces.

Timers Promises API

Timer operations are a bread-and-butter necessity in web applications. Whether setting time limits for user inputs or compensating for slow internet connections, coders devote hours to getting timing right. Considering the coding hours required, Node v16’s promise-based API for timer operations marks a productivity boost. Released with Node v15, the Timers Promises API moves to Stable status with Node.js v16.

Web Crypto API

Promise objects also figured in the decision to create a Web Crypto API for Node.js. Many developers were chilly towards this expansion. Node already has a crypto module and several prominent coders noted that Node’s cryptographic capability exceeded the World Wide Web Consortium standards. Why add still more to Node’s codebase? JavaScript’s push for promise-based development is the answer.

Promised-based development is already firmly established in client-side computing, the coding for web browsers. JavaScript cross-compatibility between client-side and server-side, along with promise objects’ aplomb for asynchronous operations, carried the day. Node’s development team has committed to keeping the Web Crypto API fully compatible with browser implementations.

Abort Controller API

Node.js v16 moves support for Mozilla’s Abort Controller API up to Stable status. Giving users the option to abort tasks is an essential function for web applications. Along with furthering the push for streamlined promise-based coding, the Abort Controller API cleans up a longtime Node coding irregularity.

A typical need for an abort option is a user-requested download operation. Before the API Controller, calls to abort downloads were handled by unsubscribing from the original API call. The requested response did not abort; the application merely ignored the result. Thanks to the promise object and the Abort Controller API, unwanted operations now promptly terminate upon user request.

V8 Version 9: More Power Under the Hood

The Node.js environment runs atop Google’s V8 Chrome engine, the same codebase underlying the Chrome and Microsoft Edge browsers. Version 9 of V8 speeds up execution times for several function calls and streamlines access times for object properties. Along with the speed improvements, the new engine supplies a long-sought solution for text management.

WebAssembly Refinements

Faster WebAssembly calls are another milestone with V8 v9. WebAssembly is an initiative from a consortium of prominent browser developers aimed at using binary code to speed typical tasks. Node.js has implemented seven of the consortium’s eight standardized features. Until V8 v9, JavaScript calls to WebAssembly functions were exasperatingly slower than JavaScript-to-JavaScript function calls. The new V8 engine finally realizes WebAssembly’s speed promise, improving execution times from JavaScript calls by upwards of 60%. 

ECMAScript RegExp Match Indices

Regular expressions are patterns used to select and filter text strings from other — often massive — text strings. Much of the internet’s power is due to coders’ ingenious use of these patterns inside the international ECMAScript standard. One shortcoming of the ECMAScript protocol involved extracting groups of text strings.

While Node.js programmers have long been able to pluck groups of substrings from a long source string, deriving the start and finish positions of each substring was a programming challenge. Though seemingly esoteric, these indexes are essential for word-processing tasks. The V8 v9 engine solves this problem by allowing programmers to add a “/d” flag to their queries. The start and finish indexes for each captured substring then appear in the match object’s indices property.

npm: New Package Mojo

The Node Package Manager has been an integral part of Node.js since the runtime environment debuted more than a decade ago. While npm v7 shipped with Node.js v15 in October 2020, the npm developer team chose to sample developer feedback before upgrading the package manager to Latest status with Node.js v16. With Node v16’s move to Long-Term Stable status, npm v7 will likely gain still more credibility. In Version 7, npm responds to three developer concerns.

Package Locks

When Facebook’s client-side package manager Yarn debuted in 2016, the application won rapid adoption among developers. A big reason for Yarn’s success was the concept of package locks. With the first installation of every package, Yarn created a package-lock file. These lock files contained the version number and dependency info on every package in a project. In addition to guaranteeing reproducible builds, Yarn’s lock files lessened the risk of importing malicious code. This security feature was a strong draw for developers.

In a move to shore up their package manager’s security, the npm team implemented its version of the package-lock scheme. Coders viewed npm’s first attempt as a step forward that fell well short of Yarn’s offering. Package-Lock Version 2, included in npm v7, is a different story.

With Package Lock v2, the npm team sought to leapfrog two shortcomings with Yarn’s lock files:

  • While yarn.lock files reliably rebuild a hierarchy tree within a given version of Yarn, different versions of the application produce different hierarchy trees.
  • Yarn’s lock files produce unnecessary duplications in the hierarchy tree with deeply nested dependencies.

The npm team believes their approach now yields leaner hierarchy trees and predictable results across versions. Secure and stable, npm’s package-lock implementation has won the respect of developers. In one more move to win over coders, npm v7 can now use Yarn package-lock files to build the hierarchy dependency tree.

Automatic Peer Dependency Installation

Dependency management is npm’s reason for being, and package dependencies fall into three categories:

  • Dependencies are the packages required for a customer-ready production application.
  • Development Dependencies are essential for testing an application in development but unnecessary for inclusion in a production app. Widely used testing packages include Babel and webpack.
  • Peer Dependencies are typically plugins required by a host package but not called by the user.

npm has long handled dependencies and development dependencies with ease, automatically parking them in the package hierarchy tree. Peer dependencies were a different story. Since npm v3, developers have been on their own for managing these plugins, with their efforts often triggering bright yellow “requires a peer” warnings. As plugins grew in popularity, so did the number of nettlesome alerts. With npm v7, peer dependency management finally goes automatic. Though long desired by developers, the npm team warns that a few applications may break with this upgrade.


In a web app context, workspaces are a way to break massive codebases into repositories of packages for maintenance and sharing among projects. A single top-level root package manages the project’s other workspaces. The Yarn package manager won developer acclaim by implementing workspaces with its first version in 2017. To address this need with npm, members of the open-source community created Lerna. Starting with npm v4, Lerna quickly became the unofficial workspaces solution for developers in the npm ecosystem.

Nonetheless, developer demand for an across-the-board workspaces solution in npm continued. With its implementation of workspaces in version 7, the npm team chose to move cautiously and explicitly stated that they were not trespassing on Lerna’s turf. Early developer reactions indicate that npm’s workspaces are highly reliable but lack the automatic features available with Yarn and Lerna. In the workspaces documentation, the npm team states that they will gauge developer sentiment regarding future workspace development. With community contributions to Lerna slowing, it looks like some programmers may be voting to move workspace management fully inside the npm house.

Observability: Two Steps Forward

In web application development, the need for observability — precisely understanding what is happening during execution — increases every year. Node.js v16 brings support for a pair of technologies to enable peering under the hood.

Async Local Storage API

Node’s Async Local Storage API boosts observability by allowing developers to monitor flows of asynchronous processes. Before the Async Local Storage API, programmers cluttered their code with test variables to glean an inkling of program flows. With the complexity of asynchronous execution, these variables often returned inaccurate values. With this API, developers can write custom monitoring code or take full advantage of commercial packages such as OpenTelemetry. Introduced at Experimental status in Node.js v12, the Async Local Storage API finally achieves Stable standing with Node v16.4.

Source Map Version 3 Support

As JavaScript has evolved, source maps have become increasingly vital for developers. When developers write JavaScript code, they aim for readability. Readable code ensures easy long-term maintenance, but it may not make for the speediest execution. To enable quicker run times, JavaScript code undergoes minification, a process that strips out comments and reduces variable names to a handful of characters. Beyond compaction, modern minification can further optimize JavaScript code by selectively reordering a programmer’s commands.

That reordering introduces a problem: When an app needs debugging, how do coders find the bug with reordered commands? Source maps are the solution. With a source map, programmers can map the problematic line in minified code back to their readable source code. This solution worked brilliantly until another JavaScript software advance. To extend JavaScript’s capabilities, some software developers marketed supersets of the scripting language. Known as transpilers, these alternatives scrupulously followed JavaScript syntax while adding additional features.

By 2019, one survey found that the majority of professionals were coding with the transpilers. This approach broke source maps and substantially reduced observability. Fortunately, coders from Google and Mozilla developed a solution: Source Map Version 3. With Node.js v16, Source Map v3 support became stable, notching a victory for observability.

SOOS: The Simple Solution to Security and Compliance 

Keeping up with the changes in Node.js and other frameworks is a prime challenge for today’s developers. Happily, as security becomes an ever-greater concern, SOOS is ready to take on the mission of software composition analysis. Security is not an option, and that’s why SOOS scans every file of every project for vulnerabilities. Matching project code against nearly 150,000 known vulnerabilities, SOOS highlights the issues and ranks trouble spots on a three-tier severity scale. No migration hassles, either — SOOS integrates seamlessly with any CI/CD pipeline for maximum productivity.

SOOS doesn’t stop there. The SOOS compliance dashboard provides a total overview of warranty, trademark, and copyright requirements. A handy wizard makes it a snap to create policies and stay on top of governance. Teams can easily generate customized SBOMs for commercial partners.

SOOS: The SCA tool that just works.