Hacker News Reader

Comment by graypegg | Hacker News Reader

Huh, oddly no mention of native browser support in the form of <script type=“module”> and importmaps! To me, that felt like the last platform to offer ESM support.

I also feel like browser support “feels” more official than support from bundlers.

Just weird to leave out a mention of that.

View on HN

It's certainly nice, and makes possible Vite's very quick reloads of developer code, but even Vite still makes (ESM) bundles for performance reasons, both for production (with everything, using Rollup) and for dev (with just the external deps, using ESBuild).

My understanding is that HTTP 2 pipelining was supposed to make requesting lots of ESM modules from the same site fast enough that bundling could be consigned to history, but for various reasons it didn't work as intended and it was ultimately removed from most browsers.

HTTP/2 “pipelining” (multiplexing) is still there and works as intended; but bundling is still much more efficient.

This article delves into just that: https://csswizardry.com/2023/10/the-three-c-concatenate-comp... The first pair of waterfall graphics illustrates the problem clearly.

(What you vaguely remember as not working as intended is probably Server Push).

HTTP protocol changes were never, ever, going to make bundling unnecessary. No one actually involved in the things said it would, or thought it would. It was less-deeply-involved people misunderstanding things that led to that popular impression.

HTTP/2’s better multiplexing helps a little, but you’ve still completely got the waterfall problem: so you have at an absolute minimum of overhead the dependency graph depth times the round-trip time—frequently multiple seconds.

HTTP/2 Server Push could have improved it in some regards, as it can in theory break out of the waterfall problem, but in practice it would have required much more complex servers, and was missing important pieces so that it was completely useless anyway (a way for the client to tell the server what resources it has cached), and they eventually just removed it all round rather than inventing and implementing the missing pieces, with which it still would have been a good deal less efficient to execute than bundling.

Minifying and bundling is just better, no matter what.

Oh yeah I assumed so. I just thought it was weird to not mention it in an article about ESM becoming the standard JS modules format. Even if it’s not the most performant use of ES modules, I still think it’s certainly the most official “signal” of support to have it in all major browsers.

> My understanding is that HTTP 2 pipelining was supposed to make requesting lots of ESM modules from the same site fast enough that bundling could be consigned to history, but for various reasons it didn't work as intended and it was ultimately removed from most browsers.

HTTP/2+ Pipelining works pretty well. (As others mentioned, it was HTTP/2 Server Push that didn't quite survive in the wild, which could have helped additional scenarios.)

I've been personally moving towards Vite's dev approach for Production (just external deps and big libraries with esbuild) and little to no bundling in dev (only external deps that don't run out-of-the-box as ESM with an importmap). A handful of small "local" files and couple big shared libraries works very well in Production in my experience.

Sadly ESM don't work with local files (file:// protocol).

That would be expected for a browser environment though! I don’t want any module my browser imports to silently import something off the filesystem without telling me.

while i agree with that, i don't quite understand why this is an issue if the main index.html file is from the local filesystem too. the filesystem should only be off limits if the main file is loaded from a website.

i suppose the problem is mixing local and remote sources. i don't know if blocking remote sources from loading local ones is enough or even easy to do. if not then that would explain why local needs to be blocked.

Most systems come with Python today, so starting an HTTP server for local testing is often a one-liner like `python -m http.server`. Anyone already working with Node has access to one-liners like `npx http-server`. (Deno and Bun also have one-liners.)

It is not that easy. You need to open console and navigate to the project directory first. While with ordinary HTML files all you need is to start typing its name in address bar (or simply never close the tab).

This isn't ESM's fault, this is the CORS security model that applies to all JS in most browsers. Some of the browser's "grandfather in" some looser restrictions for file:// origin JS files from file:// origin HTML files, with Firefox being the least restrictive I'm aware of, but you can trigger CORS blocks in all of them for JS files of many types, not just ESM. ESM just wound up on the other side of the expiration of "grandfathered in" loose restrictions for CORS checks in most browsers.

Sure, there's a learning curve to running even a one-liner localhost HTTP server, but when I was learning HTML the first time there were all sorts of strange learning curves (many of which aren't even relevant anymore).

Sure, it makes it harder to distribute things like Twine apps, but there are known workarounds (bundle all the scripts into the HTML file) that Twine already does. (I'd love to see a new well-supported "HTML app container" format/standard to download/distribute HTML apps safely. It seems unfortunate that PWAs went so deep into Service Worker mania and the simple ideas like I should be able to ZIP a folder of HTML and JS files, rename it to something like myapp.pwa and it "just work" kind of got lost in several shuffles. Sure, Service Worker-based file auto-updating is nice when it works, but it is so complicated and sometimes I just want a dumb ZIP-like file users can double-click.)

Reply on news.ycombinator.com