JS: History of CommonJS Module System. 2009 to 2026

History of CommonJS

history of CommonJS

ai answer

CommonJS emerged as a pivotal standardization effort in the JavaScript ecosystem, addressing the lack of a native module system in the language during the late 2000s. At the time, JavaScript was primarily used in browsers via <script> tags, leading to global namespace pollution, dependency management issues, and brittle code organization through patterns like the Immediately Invoked Function Expression (IIFE) or the Module Pattern. The rise of server-side JavaScript, particularly with early runtimes like SpiderMonkey and Narwhal, highlighted the need for a reusable, encapsulated module system outside the browser.

Origins and Early Development (2009)

The project traces its roots to January 29, 2009, when Mozilla engineer Kevin Dangoor published a blog post titled "What Server-Side JavaScript Needs?". In it, he proposed a standardized module system to enable modular, server-side JavaScript development, emphasizing synchronous loading for simplicity in non-browser environments. This initiative launched under the name ServerJS, focusing initially on server-side needs.

By August 2009, the project was renamed CommonJS to reflect its expanded scope beyond servers, encompassing any non-browser JavaScript runtime, such as desktop apps or embedded systems. The CommonJS group operated as an open, community-driven effort—not affiliated with Ecma International's TC39 (which handles ECMAScript standards)—where specifications were only finalized after multiple independent implementations proved viability. Early contributors included Dangoor and a loose collective of developers, with Isaac Z. Schlueter later playing a key role through Node.js integration.

The first major specification, Modules/1.0, defined the core mechanics: each file as a module, require() for synchronous imports, and exports (or module.exports) for sharing functionality. This was quickly iterated to Modules/1.1 and 1.1.1, alongside supporting specs like Packages/1.0 for dependency management.

Adoption and Node.js Integration (2010–2011)

CommonJS gained traction with the launch of Node.js in May 2009 by Ryan Dahl. By 2011, Node.js fully adopted CommonJS as its default module system, using require() and module.exports to enable reusable server-side code. This made CommonJS the de facto standard for backend JavaScript, powering the explosive growth of npm (launched in 2010) where most packages were (and still are) published in CommonJS format. Node's caching mechanism—executing modules once and reusing exports—optimized for server performance, though its synchronous nature suited I/O-bound environments better than browsers.

Expansion and Proposals (2010s)

The CommonJS project evolved beyond core modules, producing over 20 proposals for a broader API ecosystem. These included:

• Promises/B and Promises/D for asynchronous handling.
• HTTP Client/B and IO/A for network and file operations.
• Modules/Async/A and Modules/Transport series for experimental asynchronous loading (though sync remained dominant).

This "batteries-included" approach aimed for interoperability across JS runtimes, influencing tools like Narwhal and later Deno (in concept, though Deno favors ES modules).

Browser Challenges and Bundlers (2013–2015)

CommonJS wasn't natively browser-compatible, prompting workarounds. In 2013, Browserify emerged, allowing developers to write browser code in CommonJS syntax and bundle it into a single file for <script> inclusion. This bridged server and client, enabling npm modules in web apps but adding build-step complexity.

By 2015, Webpack (launched that year) built on this, creating dependency graphs for multi-asset bundling, further popularizing CommonJS in frontend workflows, especially with SPAs like React.

Transition to ES Modules and Legacy (2015–Present)

The landscape shifted with ECMAScript 2015 (ES6), which introduced native ES Modules using import/export syntax—static, asynchronous, and browser-native. This competed with CommonJS, offering better tree-shaking and no bundler requirement in modern browsers.

Node.js lagged in adoption: Experimental ES module support arrived in v8.5 (2018) and stabilized in v12 (2019), but CommonJS remains the default for backward compatibility. Today, interop is seamless—ES modules can import CommonJS via dynamic import()—and tools like TypeScript handle both.

CommonJS's legacy endures: It democratized modular JS, birthing the npm ecosystem and influencing every modern bundler. While ES modules dominate new projects, CommonJS powers ~80% of legacy Node code and remains essential for migration paths. For deeper dives, explore the archived CommonJS wiki or Node's module docs.