4 ms·
I don't see a practical difference between bundling and server push to the developer. You are still using tooling that traces your dependency graph and produces
by MatthewPhillips 10y ago
I don't see a practical difference between bundling and server push to the developer. You are still using tooling that traces your dependency graph and produces... something. In the case of a bundler it produces a concatenated script and in the case of http push it produces a list of files that should be sent with a particular route. To the developer, why should the latter be preferred over the former?
- WorldMaker 10y agoFrom a developer side, at least, HTTP/2+caching (with or without server push) is preferential in that the browser handles everything (and knows what it needs) versus bundling which is a build process of some sort. From a developer perspective, producing the only the dependency graph is still going to be faster and need less overall IO than building a bundle. You can get a sense of it today with jspm dep-cache versus jspm bundle times.
- rajivm 10y agoThree reasons off the top of my head: - Smaller cacheable objects -- every change you make doesn't invalidate the whole "bundle". - If there are many permutations of the optimal bundles: different browsers, different pages use different scripts, etc. - The browser does not need to wait for the "full bundle" to download to execute your app/site -- it can start once the first necessary assets are loaded. In one project I worked on, we had 3 bundles: - early load (inside the head tag) - deferred load secondary (after body tag, for the other site pages) - deferred load primary (after the body tag, for the 'hot' pages of the site) With a optimal http/2.0 setup, we wouldn't need to make these never fully optimal bundles.