What’s this? Looks like the future.

I also could buy import x from 'y' as module, but that doesn’t address the “what’s a module? i thought module was a synecdoche of module exports namespace exotic objects.”

Good morning, all. I wanted to reiterate a bit on what I said in plenary and also afterwards direct to Kris last week.

The layered modules APIs that Kris presented are great at permitting a bunch of use-cases. In particular I like the idea of using them for achieving mocking in a test runner (avoiding the need for code to use DI patterns or custom host hooks).

The bigger win (value proposition) is if we can identify features that will allow the wider ecosystem to adopt ES modules. npm & Node mostly ship and execute CommonJS. No one has provided a compelling or easy migration story. So we have a situation that may even be worse than the Python 2/3 switchover.

A key specific use-case that CJS still beats ESM on is the ability to ergonomically/quickly achieve fast load times via lazy loading. Meaning the Babel option "lazy" on the ESM->CJS transform that injects conditional synchronous requires to defer loading static imports to instead be just-in-time.

ESM has no ergonomic way to achieve this. Instead users are forced to rewrite their app to become async and use dynamic `import() `. Because switching sync->async functions have ripple effects back to the caller.

Originally Yulia's defer-eval proposal looked like it might solve this problem. But I understand the sync part of that proposal is now under debate.

My purpose in conveying this is not to demand sync loading. It is to highlight that, if you can make migration from CJS to ESM easier, then (1) the community/ecosystem will love you and see the value of your work, and (2) it will be easier to fund this work stream.