2 ms·
> 1. The downstream users of your backend library can use ESM JS. ESM code can use CJS packages. > 2. You can author (or output) isomorphic code that works in
by gbuk2013 2y ago
> 1. The downstream users of your backend library can use ESM JS.
ESM code can use CJS packages.
> 2. You can author (or output) isomorphic code that works in Node.js and other environments.
TS compilation makes this possible already - e.g. I have authored API SDK packages that can be used in FE and BE code.
> 3. Static analysis tools can more reliably understand your dependency graph, e.g. find unnecessary code/modules/packages.
An earlier sibling comment mentions this - this is potentially a good reason but I need to do some benchmarking to see the actual impact (would make for a good blog post one day) :)
> 4. You can use a custom load API to do customized operations. E.g. import a YAML file as a JavaScript object.
TIL but it seems like a niche feature that I would never need in BE world.
- paulddraper 2y ago> ESM can use CJS packages True. Everything is a default import, but it does work. > I have authored API SDK packages that can be used in FE and BE code. FE code can't use CJS. You need to have an extra step to convert to ESM (or AMD, webpack chucks, etc). And the general consensus is that frontend JS has too much complexity. --- CJS works pretty well for Node.js. If it didn't, it wouldn't have been adopted. The primary advantage is authors can write and distribute isomorphic code. (Again, without relying on heavy or kludgy module system conversations.)