Does this mean that in theory i could skip the build/bundling step entirely?

E.g. i could have a backend project in whatever language i wanted but then instead of having an npm frontend project, instead i could:

    1. use a jsconfig.json and jsdoc to gradually type with typescript but without need for tsc since my editor gives me feedback anyway 
    2. use es modules to handle splitting and caching the various .js files of my app
    3. use this import maps feature so that i can still gzip and add the digest of the file to the filename so that i can safely say cache every .js forever since if theres a change, the filename will differ and this feature means i can still import from friendlyname rather than friendlyname-hashed-value

Optimal file transfer - all in one js bundle, but if i have http2 then i don’t care because the overhead of multiple files is gone

minify - i don’t care since i gzip anyway

sourcemaps - i dont care since the files presented to the browser are the ones i wrote, maps are redundant

I quite like react but i think i’d like simplifying my tool chain more and using something like htmx instead.

EDIT: i want to qualify the “i quite like react” statement, i have pure components only, no useState, for state handling in the small i’m fine with pure useReducer’s but zustand is nicer for my cases since i can also use that to prevent subtree re-renders of the reducer/context barebones approach.

You still need a bundler because browsers will process only ~6 HTTP requests at a time, so if your code (with all dependencies) has many JS files you will be throttled by that limit real quick. HTTP2/3 makes parallel fetching more efficient over the wire but does not change the limit of max concurrency imposed by the browser.

I actually think the main issue isn't number of requests, but that you can't know which additional files you need to load before loading some of them. Aka if you have a moduleA depending on moduleB depending on moduleC. Only after downloading moduleB will you know that you have to download moduleC as well. So with a deep tree this quickly becomes very slow?

This is the problem Preload headers & Early Hints are meant to help with. https://web.dev/preload-critical-assets/ https://developer.chrome.com/blog/early-hints/

You need some server-side intelligence to analyze each module & determine what preload headers to send. But then the browser knows what to request, even before content starts coming.

If it's calculated at deployment time, it's functionally the same cost as making a bundle, without its benefits.

If it's calculated at runtime, it's an additional cost & delay, plus you'd need a specialized server (or at least middleware) to handle the requests.

People harp on and on about the benefits of bundles for compression, but man, it's so shortsighted & stupid. It favors only the first-load situation. If your user actually comes back to your app, these advantages all go away, disappear. Personally I'd rather help people that use my app regularly.

Second, the days of bundles being better at compression are numbered. Work has been ongoing to figure out how to send compression dictionaries separately. With this, 98% of the compression advantage disappears out the window. https://github.com/WICG/compression-dictionary-transport

Neither of your approaches sounds like what I'd do. Personally I would build an http server that takes raw uncompressed source. When asked for a file the first time, it compresses & builds the dependency maps in parallel, & saves both of these out, maybe a .gz with some xattr on it. Or store that data in memory, whatever. The first user gets a couple extra ms hit, but the server transparently still does the thing. Developer mode is just a tool to watch the file system & clear those caches, nothing more, & can potentially be completely separate.

Bundles are just so awful. They complicate what used to be an elegant understandable clear world of computing. We can & should try to get back to resources, if it makes sense. And the cards are lining up to make this horrible un-web un-resourceful kludge potentially obsolete. I'm excited we might make the web make sense again for end-users. They deserve to be out of the bad times.