I swear, if I have to explain one more time to people that a JS module system cannot actually break the laws of physics for network latency and magically make browser module loading work...
Like, can this fucking myth of "ESM works in the browser" please die already, I am so so tired of it
I saw a post earlier that basically said "the software development world absolutely has its own version of antivaxxers" and this feels like it just further confirms it
Like, how could a belief that is so obviously false once you actually reason through it ("ESM is viable for direct use in the browser"), and so frequently disproven by people still using build tools in practice... still become canonically accepted as true?
(See https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3?permalink_comment_id=4578418#gistcomment-4578418 for the details)
@joepie91 i realize i'm jumping into something where i don't have context, but this seems like it kinda depends? like, if code to render the site is a bunch of modules deep then sure, but if the site paints without javascript (which is good to aim for anyways) then using ESM seems fine, since the latency to load the javascript probably isn't a big deal.
@alive Time-to-paint is not the only metric that matters - time-to-interaction does too. And that's absolutely affected by network latency on most modern websites (and widely recognized as important too!).
So at that point the question becomes "is it worth removing a single fully-automatable build step from the development process, at the cost of making the site considerably slower for everybody?" - and as far as I am concerned, the answer to that is a resounding "no".
And indeed, in practice virtually every ESM-based development stack uses a bundler somewhere in the process; sometimes without the developer being aware, sometimes with the stack deliberately using different words to avoid calling it a bundler.
@joepie91 do you think that the benefits of reducing the size of individual bundles and not loading uncommonly-used parts of the code for every visitor are just not big enough to matter in practice? (or is there a easy way to do that sort of thing with CJS that i'm not aware of?)
certainly it makes sense to me to say that most sites that use ESM directly would be better served by bundling, but it does seem to me like there are tradeoffs, and there are times when it's reasonable to use ESM.
@alive It does often make sense to split up client-side code into different chunks depending on what is commonly-used, yes - but crucially, those boundaries don't align with import boundaries and that's why for this purpose you use a bundler that can do bundle splitting.
Trying to use ESM natively is a terrible solution to this in virtually every case, because there's going to be way more import operations than you actually need 'cutoff points'; leading to needless network latency.
Bundle splitting is also possible regardless of module system, and does not in any way require ESM - once you're bundling, the bundler can do whatever it wants, including lazy-loading and code rewriting. So this works fine with CJS. Just like unused dep elimination works fine with CJS, despite common claims of it being an ESM-specific feature.
(In fact, both were done with CJS already before ESM even existed.)
@joepie91 yeah, that makes sense. the cases where i've used it and felt like it's a good solution are ones where i'm writing all of the code myself, makes sense that it would work poorly if you're using libraries or not writing with that specifically in mind.
i don't really follow anything js ecosystem related so i was basically unaware of the hype around it until just now 😅