Hacker News Reader

Comment by somehnacct3757 | Hacker News Reader

I keep thinking how QUIC / HTTP/3 would go nicely with ESM in the browser (via script tags with type=module) for simple sites.

A webmaster could totally avoid the complexity of learning a JS tool chain. Right now even 1000 lines of JS has you reaching for a bundler. It would make shipping a small html+css+js site again as simple as dragging files to your webserver.

View on HN

Bundling will not go away as it solves a different problem of how to best distribute the app to final users. When authoring code, you want to have many small files so you can keep related logic blocks isolated from the rest. When distributing the code, you want to ship a few larger files to reduce network overheads. Any non-trivial frontend app will call code from 100+ files, and your browser is tuned to request these files ~serially (or in serial batches of 8-10) which becomes frustrating very quickly even on localhost.

Worse, even if they were all fetched in parallel, you would still see terrible loading times simply because a dependency graph can only be traversed depth-wise serially. Doesn't matter what network protocol you use or how parallel it is.

This is not true at all. For every module you can parse out and load the module's imports in parallel. As you traverse the graph the known and loadable module frontier can grow much wider.

The only way it would be serial is if every module only imported one other module.

Note how I was specifically talking about depth-wise.

Fair, though that wasn't clear.

So then even without modulepreload or bundling, it's not always going to be true that the longest import depth is the limiting factor. Earlier loaded modules can still be parsed in parallel while dependencies are fetched, and completed subtrees can be linked and evaluated. Given that modules are deferred and can be imported early, there's often time for parallel work.

I'm not following. Dependencies can be nested, so you cannot assume that a dependency by a given name can be satisfied by a previously loaded dependency by the same name. Which means you still need as many serial roundtrips as there are depth levels, whether you parse in parallel or not.

Sure, you can cut down on the delay introduced by the parsing, but 10 depth levels over a 100ms connection is still going to take a second to fetch, because you simply can't know the N+1th dependency until you have at least completed the Nth roundtrip.

QUIC / HTTP3 does not fix the roundtrip wait times caused by dependencies - if 'a.mjs' imports 'b.mjs' which in turn imports 'c.mjs'... you still need two roundtrips to load all three.

only a bundler can fix that (or a hypothetical process which would set up preloads for all required libraries, but that would just be a bundler without the actual bundle creation step)

An ES module-aware server can avoid that problem by using HTTP Server Push[1], but I haven't seen a production-quality implementation of that, only proof-of-concepts.

[1] https://medium.com/@nikita.malyschkin/the-future-of-web-depl...

Server push is being deprecated because it was far to hard to implement correctly. A server that knows the dependency graph could inject <link rel=modulepreload> into the HTML though.

Reply on news.ycombinator.com