stay here or leave tomorrow? • DEV CLASS

CommonJS (CJS), a standard for modules in JavaScript, is still widely used despite being superseded by an official JavaScript standard called ECMAScript modules (ESM), leading to hot debate on the future of CJS.

Andy Jiang, Deno’s product marketing manager, posted that JavaScript is “sabotaged by its own baggage of the past…CommonJS.”

Deno is a JavaScript or TypeScript runtime created by Ryan Dahl, also the inventor of the older Node.js runtime. Deno was intended to be a modern equivalent of Node.js, solving problems Dahl had observed with the earlier effort, and one of its features is top-notch support for ESM. That said, due to the widespread use of CJS modules, Deno got a “Node.js compatibility mode” in version 1.15, and since improved, that supports CJS modules. According to the docs, “CommonJS resolution is implemented as in Node.js and there should be no discernible differences.”

However, Jiang’s argument is that CJS has inherent problems, including loading modules synchronously, less susceptibility to “tree shaking”, where unused code is removed before being bundled for deployment, and the main problem is that it is not browser-native . CJS modules must be transposed before deployment, if they are to run in the browser, which means a build process is required.

However, Node.js is the dominant JavaScript runtime for use outside the browser and was established before ESM was standardized. The Node team added support for ESM but also continued with CJS compatibility. Many Node.js libraries require CJS and developers used to Node don’t have a strong incentive to switch. The other option for library developers is to support both, which adds both a bloat and a maintenance burden.

It’s easy to say, as Jiang does, that “CommonJS just isn’t enough. ESM is a better solution for developers”, but it does not disappear.

Bun creator Jarred Sumner, whose JavaScript runtime based on the Zig language and JavaScriptCore engine has attracted attention for its speedy performance, entered the debate last week with a post refuting the Deno pitch. Sumner noted statistics from late last year showing CJS package downloads at 73.6%, far ahead of ESM. “We believe that better tooling can solve today’s developer experience issues with CommonJS and ESM interop,” said Sumner.

Sumner also said that CJS modules boot faster. “ES modules are designed slower. They need two passes to tie imports to exports,” he said. This can be a problem in the case of serverless applications that constantly launch new instances. In one benchmark, “with Node.js the difference was 1.8x)” for a cold boot, Sumner said.

However, his main point is that millions of npm modules use CJS, some of which are no longer actively maintained and will never be updated, but “remain critical to existing projects”. According to Sumner, “we will never reach a point where all packages can be expected to use ES modules”.

Bun supports both ESM and CJS, and Sumner added that “As of Bun v0.6.5, the Bun runtime natively implements CommonJS”, as opposed to transpiling CJS modules into some form of ESM.

The dilemma with obsolete technology is that the longer it’s supported, the more time it takes to replace it; but not supporting it entails high costs. The late arrival of Node compatibility in Deno perhaps shows that Dahl’s team made wrong assumptions about developers’ willingness to move, despite technical advantages in ESM. Despite the publication of CJS’s shortcomings, Deno is practically forced to support it.

A debate on Hacker News shows that developers are also divided on the subject. Node is making the same mistake that Microsoft made with Windows, that Apple didn’t make with OSX – instead of letting go of a system that has outgrown and forcing the user base to grow, they cling to the old way and the old API, said one developer; but another said that “the benefits of ESM are not compelling enough to rewrite everything. Loading browser-native modules is a niche use case that can never be as performant as bundling.”