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*

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.

🤷 We can just give them all the facts and they can make their own decisions on the tradeoffs until we make ESM more viable. Depending on your tradeoff choices, shipping dual or even CJS-only can be a very good decision the way things are today.

Yes, ESM is standard syntax from a decade ago, and yes, we should finish the transition by shoring up all its remaining tradeoffs. At that, let's call it legacy and encourage everyone to move forward. But the work isn't done yet, and we shouldn't pretend it is just because lots of time has passed.

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

I think Marco is mainly talking about new libraries though.