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.

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.

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.

0 reposts3 likes

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".

🤷 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.

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

That would be so nice. There's still some misunderstanding - people seeing it as being given a choice of two non legacy formats, and you choose the one you prefer. Marking it as legacy would clear a lot of that up