Post

I get the desire for ESM for things like tree shaking (though I'd like to see some numbers on impact here). I get the nicer syntax. But, unbundled ESM takes about 2x as long as CJS to load in my tests (can show if desired). If your users aren't bundling ESM opts them in to big a load-time perf hit.

This more or less confirms what @jarredsumner.com observed almost 2 years ago. bun.sh/blog/commonj...

CommonJS is fine, its not gonna go anywhere but its legacy. The effort needs to go into making esm better and working with APM. The answer is not "use commonjs", but work on the spec

100% agreed on all counts, but with the nuance of: Library authors who care about their users' cold-start times on unbundled apps should continue to ship CJS until ESM load performance is improved, and that's not as niche a use case as it may sound to some folks.

I believe they should switch to esm anyways and push for the improvements in the right forum

Why not both push for improvements and allow users to prefer performance at the same time?

Because standardization favors improvement. If we all use the same thing its easier to unite and make that thing better. CommonJS should be marked as legacy and it's something I plan to do. Basically say, we switch our efforts to esm and make it first class citizen. Don't use it for new projects.

Dont use CJS for new projects*

We agree on the destination, at least in principle. I'm just not on board with "let's ask library authors to make things worse for some of their users in order to influence the platform (i.e. Node.js, V8, TC39) to make it better".

Let's ask library authors to support the dual module system is much worse than let's ask authors not to use the standard module system because of startup performance.

But library authors are already outputting to both esm/cjs and it takes virtually zero effort to continue supporting both module systems