Is there really any point to webpack now that we have http2? I'm looking for a way to code split all the things and webpack is making that difficult. I want cache performance over download speed now that I've gone mobile only on data.
There is still a protocol overhead for each request compared to a single concatenated file.
The compression of the single large file is better than many small files.
Servers are slower serving many small files than a single large file.
I'm really less interested in speed though. I want to optimize for file transfer bandwidth. Going all mobile data for a week has shown me two problems. JS has severely bloated websites, and staying up to date with software patches is expensive. In both cases, the amount of new material being transferred is very low. A point update on a JS library or patch is a few lines change, but we must download the entire library again. Compounding this for JS is every site using the same libs are sending the same data, because of browser origin policies. One way around that is CDNs, but then you are submitting to a centralized point of failure/spying.
Sending the whole file again is the easiest route for developers, but the most expensive for mobile only cord cutters.
Webpack does that with chunk hash. Common chunks go into common.js, and my app goes into app.js, if I change my app's JS, only app.js gets downloaded which is probably 50kb whereas common.js is maybe 300kb.
The point is there is a tradeoff between speed & efficiency. If every line of code were its own file, you'd have a high amount of efficiency when only 1 line changes, but loading that would be a nightmare on mobile.
I asked this same question and got down voted for it. After probing some more though, I found out it's only any use for people that have many MBs of JS files. Which I can only assume comes from piles of npm dependencies getting sucked into their projects.
Also, it's not for websites with some interactivity, it's for big giant web apps... apparently.
