tech hot take
@dysphoricunicorn actually, ESM offers nothing over CommonJS, and just caused terrible ecosystem fragmentation resulting in issues like what you're facing. https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3
tech hot take
@dysphoricunicorn it offers native browser support but
> And then people go "but you can use ESM in browsers without a build step!", apparently not realizing that that is an utterly useless feature because loading a full dependency tree over the network would be unreasonably and unavoidably slow - you'd need as many roundtrips as there are levels of depth in your dependency tree - and so you need some kind of build step anyway, eliminating this entire supposed benefit.
the standard choosing ESM was a big mistake, they should've standardized on commonjs (which effectively already was), instead of inventing something worse and expecting everyone to switch
tech hot take
@f0x I don't consider it useless even if it may not work well for large scale apps
it might not have been the best standard to use but that doesn't change anything about the fact that it's here now and it won't be replaced. I generally prefer using language features over stuff that needs some third party to support it
tech hot take
@f0x despite what the post claims, ESM offers native browser support (according to caniuse for 95% of all users) while cjs is one of too many solutions that all need third party libs and bundlers to work.
Like it or not, ESM is what the official standard adopted and sticking with solutions that were developed because there was no official standard is what's causing the fragmentation to stay bad