Frameworks like Vite use a technique where they don’t bundle application source code in development mode. Instead, they rely on the browser’s native ES Modules system. This approach results in incredibly responsive updates since they only have to transform a single file.
However, Vite can hit scaling issues with large applications made up of many modules. A flood of cascading network requests in the browser can lead to a relatively slow startup time. For the browser, it’s faster if it can receive the code it needs in as few network requests as possible - even on a local server.
I’m trying to understand the “scaling issues” personally. My current understanding is that vite performs many initial requests when it loads the dependency tree of third party modules.
Bundlers outperform Native ESM when working on large applications.
This is very much depends on how/why your application is large. Is it large because it has many (hundreds) pages but each page is relatively small? Then you likely are better off with native esm because each page will load quickly. Is it large because you have few (a single) pages and they do a lot of heavy lifting (think a game, or something like Figma where it’s all a single page essentially)? Then bundling will likely be better because you’ll have fewer overall points where you are loading code and you’ll want those load points to be as optimized as possible.
A flood of cascading network requests in the browser can lead to a relatively slow startup time.
This is true, however it implies that these esm network requests will always be cascading.
My overall reaction: I don’t write enough JS for these things to really change my development practices. If I REALLY need some JS, I write esm modules/web components. If I REALLY need a build step (likely because I’m using a JS package) I tend to lean towards esbuild because it’s small/simple. Especially for Elm centered projects, bundling/building JS is going to be your build bottle neck.