4 ms·

Therefore import maps do not solve all problems, bundling "compiler" solve. Even with HTTP/2 there is "some" overhead when loading lots of small files. There

Therefore import maps do not solve all problems, bundling "compiler" solve. Even with HTTP/2 there is "some" overhead when loading lots of small files. There is also no tree-shaking e.g only loading functions which are really used.

WorldMaker 4y ago
> There is also no tree-shaking e.g only loading functions which are really used. In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.
mythz 4y ago
They have different trade-offs sure, where bundling typically creates large opaque blobs of JS used by the entire SPA resulting in large initial download & parsing/execution time which is why it's preferable to only download & execute code needed which is easy to achieve with cohesive modules. The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests. [1] https://qwik.builder.io https://qwik.builder.io
Joeri 4y ago
If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading one big file and 100 little ones. Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries. As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint. I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.
- galaxyLogic 4y ago
  > there’s no real difference between downloading one big file and 100 little ones. Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response. It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.
  - WorldMaker 4y ago
    HTTP 1.0 when every request/response pair was a separate TCP connection certainly was a huge deal for one big file versus 100 little ones. HTTP 1.1 shifted the dynamic a bit, when properly configured. HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.) There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).

WorldMaker 4y ago

> There is also no tree-shaking e.g only loading functions which are really used. In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.

mythz 4y ago

They have different trade-offs sure, where bundling typically creates large opaque blobs of JS used by the entire SPA resulting in large initial download & parsing/execution time which is why it's preferable to only download & execute code needed which is easy to achieve with cohesive modules. The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests. [1] https://qwik.builder.io https://qwik.builder.io

Joeri 4y ago

If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading one big file and 100 little ones. Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries. As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint. I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.

galaxyLogic 4y ago
> there’s no real difference between downloading one big file and 100 little ones. Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response. It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.
- WorldMaker 4y ago
  HTTP 1.0 when every request/response pair was a separate TCP connection certainly was a huge deal for one big file versus 100 little ones. HTTP 1.1 shifted the dynamic a bit, when properly configured. HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.) There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).