I don't think you understood the question. HTTP/2 allows for one connection to the server to stream multiple files. There's no more network setup penalty for making a request. So all that remains is downloading the files. Now it doesn't matter if they're in one bundle or 20 files.
You also don't have to tree shake up front because the execution will do it at runtime. If you deploy some unused modules, the browser will never request them and the server will never send them.
For the remaining benefits I can think of - more bundle bytes means more optimal compression; or shaking out functions within a module - I'm not so sure the benefits outweigh the complexity of maintaining and using bundlers. We could be splatting the src directory straight to the server and letting HTTP/2 do the rest.
I think you didn't understood my answer ;-) It still matters if it is one file or 20 (for example for file server loads). Then requesting 20 files separately (even on established connection) doesn't bring you a profit, as even HTTP/1.x browsers try to keep connection "alive".
What HTTP/2 brings here is a possibility to push to client files in advance so you can do a bit of "prebundling" on server side. Heard of couple different techniques of "prebundling" on server side BUT none of them will be as simple and performant as bundling it yourself :-)
(and want to make sure that you realize that: there is no profit if modules will be requested from server at runtime)
And I guess you never tired things like terser (https://terser.org/docs/api-reference) so you don't know how much profit it brings not only in a bundle size, but also a startup performance and even runtime performance. Try it, play with different hoisting and mangling options (especially test mangling properties) and check the memory consumption, startup times and performance of your code.
Not sure what you're talking about and if you know what you're talking about here: "more bundle bytes means more optimal compression; or shaking out functions within a module"
But to give you a hint will tell you to: compress src directory of your project and compress bundled and minified source of your project. See yourself what performs better ;-)
Your condescending responses are infuriating. Of course I have used terser, and before it uglifyJs, and am familiar with all the intricacies of mangling, compression, and other minifying techniques. I've also maintained many bundler configurations across different bundler solutions.
I'm not looking for a mentor to explain the basics of bundler technologies or asset compression. I'm asking if HTTP/2 reduces the advantages of these techniques to the inflection point where the complexity of using bundlers is no longer worth the squeeze.
"more bundle bytes means more optimal compression" - this alludes to a single bundled file taking better advantage of the compression dictionary than many small files, who can't share dictionaries when compressed.
"shaking out functions within a module" - this is another form of tree shaking as opposed to file-based tree shaking (import dependency analysis). Unbundling could compete with the file-based case, but not with a deeper analysis of unused functions _within_ files.
These were the remaining advantages I could think of, I'm sure there's more. It sounds like you think bundling is still the way to go, and I probably agree, but it doesn't make any less interesting a discussion about its remaining merits and if we can iterate to close the gap. Bundlers, minifiers, sourcemaps, are all complicated build tools that require a hand on the wheel to maintain in the long term. We should not settle for them as defacto js ecosystem techniques.
Sorry for that, for my excuse it was not my intention.
Bundlers, minifiers, sourcemaps, are all complicated build tools that require a hand on the wheel to maintain in the long term.
It just shows how bad is design of JS and web. But there are tools that do it nearly all with just one command, check "rollup" or my recently favorite "esbuild" (if you didn't before)
We should not settle for them as defacto js ecosystem techniques.
I think it's done, it's settled, as JS itself, and if we like it or not, we have to live with it. :-)
Still hoping that one day will come real web 2.0 and HTML, CSS, HTTP, JS and even webassembly will be taken as "lessons learnt", thrown away and replaced with something way more logical, structured and extendable
Comments
I don't think you understood the question. HTTP/2 allows for one connection to the server to stream multiple files. There's no more network setup penalty for making a request. So all that remains is downloading the files. Now it doesn't matter if they're in one bundle or 20 files.
You also don't have to tree shake up front because the execution will do it at runtime. If you deploy some unused modules, the browser will never request them and the server will never send them.
For the remaining benefits I can think of - more bundle bytes means more optimal compression; or shaking out functions within a module - I'm not so sure the benefits outweigh the complexity of maintaining and using bundlers. We could be splatting the src directory straight to the server and letting HTTP/2 do the rest.
I think you didn't understood my answer ;-) It still matters if it is one file or 20 (for example for file server loads). Then requesting 20 files separately (even on established connection) doesn't bring you a profit, as even HTTP/1.x browsers try to keep connection "alive".
What HTTP/2 brings here is a possibility to push to client files in advance so you can do a bit of "prebundling" on server side. Heard of couple different techniques of "prebundling" on server side BUT none of them will be as simple and performant as bundling it yourself :-) (and want to make sure that you realize that: there is no profit if modules will be requested from server at runtime)
And I guess you never tired things like terser (https://terser.org/docs/api-reference) so you don't know how much profit it brings not only in a bundle size, but also a startup performance and even runtime performance. Try it, play with different hoisting and mangling options (especially test mangling properties) and check the memory consumption, startup times and performance of your code.
Not sure what you're talking about and if you know what you're talking about here: "more bundle bytes means more optimal compression; or shaking out functions within a module"
But to give you a hint will tell you to: compress src directory of your project and compress bundled and minified source of your project. See yourself what performs better ;-)
Hope helped you!
Cheers!
Your condescending responses are infuriating. Of course I have used terser, and before it uglifyJs, and am familiar with all the intricacies of mangling, compression, and other minifying techniques. I've also maintained many bundler configurations across different bundler solutions.
I'm not looking for a mentor to explain the basics of bundler technologies or asset compression. I'm asking if HTTP/2 reduces the advantages of these techniques to the inflection point where the complexity of using bundlers is no longer worth the squeeze.
"more bundle bytes means more optimal compression" - this alludes to a single bundled file taking better advantage of the compression dictionary than many small files, who can't share dictionaries when compressed.
"shaking out functions within a module" - this is another form of tree shaking as opposed to file-based tree shaking (import dependency analysis). Unbundling could compete with the file-based case, but not with a deeper analysis of unused functions _within_ files.
These were the remaining advantages I could think of, I'm sure there's more. It sounds like you think bundling is still the way to go, and I probably agree, but it doesn't make any less interesting a discussion about its remaining merits and if we can iterate to close the gap. Bundlers, minifiers, sourcemaps, are all complicated build tools that require a hand on the wheel to maintain in the long term. We should not settle for them as defacto js ecosystem techniques.
Sorry for that, for my excuse it was not my intention.
It just shows how bad is design of JS and web. But there are tools that do it nearly all with just one command, check "rollup" or my recently favorite "esbuild" (if you didn't before)
I think it's done, it's settled, as JS itself, and if we like it or not, we have to live with it. :-)
Still hoping that one day will come real web 2.0 and HTML, CSS, HTTP, JS and even webassembly will be taken as "lessons learnt", thrown away and replaced with something way more logical, structured and extendable
;-)
;-)