Module systems in JavaScript and Node.js
Not all programming languages come with a built-in module system, and JavaScript lacked this feature for a long time after its inception.
When writing JavaScript code for the browser, it is possible to split the code base into multiple files and then import them by using different <script> tags. For many years, this approach was good enough to build simple interactive websites, and JavaScript developers managed to get things done without having a fully-fledged module system.
Only when JavaScript browser applications became more advanced and frameworks like jQuery, Backbone, and AngularJS took over the ecosystem did the JavaScript community come up with several initiatives aimed at defining a module system that could be effectively adopted within JavaScript projects. The most successful ones were asynchronous module definition (AMD), popularized by RequireJS (nodejsdp.link/requirejs), and later universal module definition (UMD—nodejsdp.link/umd).
When Node.js was created, it was conceived as a server runtime for JavaScript with direct access to the underlying filesystem so there was a unique opportunity to introduce a different way to manage modules. The idea was not to rely on HTML <script> tags and resources accessible through URLs. Instead, the choice was to rely purely on JavaScript files available on the local filesystem. For its module system, Node.js came up with an implementation of the CommonJS specification (nodejsdp.link/commonjs), which was designed to provide a module system for JavaScript in browserless environments. It’s worth noting that CommonJS was not part of the official ECMAScript standard, but an independent initiative to standardize JavaScript outside the browser.
CommonJS has been the dominant module system in Node.js for many years. It became so popular that people started using it to write modules that could be used even in browser applications thanks to module bundlers like Browserify (nodejsdp.link/browserify) and Webpack (nodejsdp.link/webpack).
In 2015, with the release of ECMAScript 2015 (ES2015), there was an official proposal to define a standard module system for JavaScript: ES modules. ES modules bring a lot of innovation in the JavaScript ecosystem, and, among other things, they try to bridge the gap between how modules are managed on browsers and servers.
ES2015 defined only the formal specification for ES modules in terms of syntax and semantics, but it didn’t provide any implementation details. It took several years for browser companies and the Node.js community to develop strong implementations, with Node.js offering stable support for ES modules starting from version 13.2 (released in 2019). As a result, the transition from CommonJS to ES modules has been somewhat slow and, during the transition years, developers have been using various techniques to publish dual-mode libraries that can work with both ES modules and CommonJS.
Today, ES modules are the widely accepted standard module system for JavaScript and Node.js. While CommonJS is still common in legacy code bases and older libraries, most new projects are now written using ESM, and CommonJS usage is expected to decline over time. This book uses ES modules for all code examples, but we will also examine some CommonJS code to understand how the two module systems can work together.
