4 ms·
Am I the only one believing common js was super ok and don't like esm? Or put differently I didn't see the necessity of having esm at all in Node. Let alone the
by hollowturtle 1y ago
Am I the only one believing common js was super ok and don't like esm? Or put differently I didn't see the necessity of having esm at all in Node. Let alone the browser, imagine loading tons of modules over the wire instead of bundle them
- gregoriol 1y agoYou can still bundle them, maybe you even should. Webpack still does a good job. Can also remove unused parts.
- hollowturtle 1y agoIf anything bun proves that both worlds can go together despite what proponents of web standards says
- jay-barronville 1y ago> If anything bun proves that both worlds can go together despite what proponents of web standards says Sure, but Bun's implementation is a confusing mess a lot of times. I prefer them separate. Note: This is no shade toward Bun. I'm a fan of Bun and the innovative spirit of the team behind it.
- spixy 1y agoYes. Also CommonJS does not support tree shaking.
- hollowturtle 1y agoNor does ESM if you import * as. Plus I believe it can be made to support tree shaking Edit: the proof my point reside in the many libraries which have an open issue because, even if ESM, they don't support tree shaking
- WorldMaker 1y ago`import * as` is still treeshakeable and Browsers will do it in-memory as the imports form weak proxies. Bundlers can treeshake it, it is just harder to do, and so it hasn't always been a priority feature. esbuild especially in the last few years has done a lot of work to treeshake `import * as` in many more scenarios than before. Sure it isn't treeshaking "all" scenarios yet, but it's still getting better.
- realityking 1y agoThe fact that ESM exports are static - and imports are mostly static - allows for a lot more dead code removal during bundling. That alone is a big win IMHO.