Sometimes I feel like I am the only human on Earth who likes ES Modules end to end, 100 %. Ecosystem divide? What would be the point of ESM if it did not do th

Sometimes I feel like I am the only human on Earth who likes ES Modules end to end, 100 %. Ecosystem divide? What would be the point of ESM if it did not do this? We could have kept using `require`s if the bar is that the new, language-native module system must not cause any sort of a transition period where people adopt it and displaces the previous ad-hoc (IMO anti-) patterns that were used for "modules" before ESM. Doesn't work everywhere yet? The support is growing and developers IMO should learn about and default to ESM. That's how the support and availability of packages will continue to grow to eventually 99.9 displace previous methods. > And then there's Rollup, which apparently requires ESM to be used, at least to get things like treeshaking. Which then makes people believe that treeshaking is not possible with CommonJS modules. I am not convinced the people referred to here are real humans and not made up to support the author's argument. Babel's problems are Babel's problems, ESM is not the cause of the problem here. > ESM in browsers without a build step!", apparently not realizing that that is an utterly useless feature A hands down amazing feature, something I was pining for for so long and it is finally here. Performance? Sure, if you are building high traffic sites, you will still reach for a bundler, but browser ESM without a build step will allow many intranet and low traffic Internet development teams to ship much nicer code than they do now after buying into bundle-everytime voodoo. If this existed before WebPack, so much spaghetti code could have been avoided. The point of static analysis I can't comment on as I have never authored any tools for static analysis of JavaScript codebases using modules, but if I were to, I would be very happy to have an actual language feature for modules with a spec at hand rather than a bunch of IMO ugly patterns that only existed out of necessity because the module system at language level took long to arrive. > CommonJS is so ubiquitous in Javascript-land nowadays that it will never fully go away Unfortunately true, but that doesn't mean we shouldn't strive for something better. I know the author used the word standard and it can be interpreted many ways, but ESM is IMO better because it is a feature of the language, not the ecosystem. > The vast majority of people who believe they're currently using ESM, aren't even actually doing so - they're feeding their entire codebase through Babel, which deftly converts all of those snazzy import and export statements back into CommonJS syntax. But browsers supporting ESM directly is somehow a problem? It's better to rely on bundlers for everything even at the cost of them doing stupid shit like this by default? Not to mention this is completely configurable and avoidable with minimal amount of effort. > the following pattern is simply not possible with ESM That's a good riddance from me! ESM being statement keywords and not expression keywords (aside from dynamic imports) is IMO the right choice. > do you want to be able to use ESM-only dependencies Yes, please. > You've destroyed a successful userland specification I am happy to have contributed to proliferation of a successful kernel specification if we're sticking with this metaphor.