4 ms·

The benefits to native bundling are huge. I really cannot overstate how much they will improve UX, and DX. The core web file formats: JavaScript, CSS, HTML, an

The benefits to native bundling are huge. I really cannot overstate how much they will improve UX, and DX. The core web file formats: JavaScript, CSS, HTML, and images, do not have native multi-file bundling support. Today's bundlers have to jump through serious hoops, which drastically reduces the effectiveness of the network cache, to emulate bundling. And those hoops bring constraints that limit the native features of the web platform that are usable with bundlers. JavaScript is bundled by significantly rewriting it. At the very least imports and references to imports have to be rewritten. Live bindings from modules require special care. Dynamic import() is severely restricted. import.meta.url usually doesn't work well, or at all. Base URLs for all resources are changed, so getting assets with new URL() and fetch() is usually broken. That causes bundlers to support importing module types that the browser doesn't support, so at development time you still have to run the bundler. The whole thing just diverges from standard semantics. CSS is bundled by assuming a global CSS scope so that the individual files are not needed separately. URLs within the CSS have to be rewritten. The upcoming CSS Modules specification allows JS modules to import CSS, but since you need to import the actual stylesheet you want, and CSS doesn't have it's own multi-module support, you really need native bundling to make this work well in production. Images can be bundled _sometimes_. Maybe a spritesheet will work, or data: URLs. It all depends on how you're using them. It's all a complicated mess that requires complicated tools and WebBundles just fix it all. You no longer have to rewrite any references in any files. If you do build files, it's purely for optimization, not because you have to. What's important for users is that files in a WebBundle are individually cached. This makes it finally possible to do delta-updates on pages where you only send the updated files. Maybe the initial visit is with a bundle and subsequent visits use HTTP/2 push. Maybe when you deploy you build delta bundles against the previous X versions of the site. With current bundlers only the bundle is cached so you can't do this at all.

jmull 6y ago
Thanks. That's all good. But I don't think this "...WebBundles just fix it all" is going to happen. I think it's going to be: web bundles is (yet) another option, with its own pros, cons, caveats, learning curves, migration challenges, support, etc. That's just how I see it, I know I can easily be wrong. If it takes off, we'll be able to measure its value by penetration. E.g., if it's being used on 1% of sites, that means it has some decent niche value. If it's being used on 10% and rising sites, we'll know it has really good value.
jiggawatts 6y ago
Explain to me why any of this is necessary once HTTP/3 is widely adopted? Isn't the whole point of HTTP/3 to "emulate" bundling without actually requiring content to be zipped up into a binary blob? Isn't it also quite good at caching, such as incrementally updating individual files without complexity? Isn't it also capable of pipelining a bunch of small logical files into a contiguous stream as-if they were in one big blob? Isn't the head-of-line blocking issue, which HTTP/3 solves, going to be a problem with monolithic web packages? What's next... WebPackage 2.0 with a yet another head-of-line-blocking-solution!? This all feels like the left hand not talking to the right hand at Google. It also feels like Google is perfectly happy to bloat web standards to the maximum extent possible given the size of their development team, permanently and irrevocably blocking anyone from ever again developing a web browser from scratch to compete with Chrome. Unless of course they can devote a few thousand man-years to the task. Which noone short of two or three companies can now. I've never even heard of this "problem" that Google is trying to solve, but clearly Google is pushing very hard for it to be solved... for some unstated reason. From the outside, this feels incredibly self-serving.
- spankalee 6y ago
  HTTP/3 is just HTTP/2 over QUIC, fixing head-of-line-blocking will help some, but... Having spent lots of time trying to optimize servers to correctly utilize HTTP/2+push, and building bundle-less deployments, not only is it quite difficult, it doesn't achieve the compression performance that bundling does. We measured ~30% better compression from a bundle over separate files. And I don't see this as bloating standards at all, but fixing a huge problem in current web development and paving a cow path. Bundlers are central to web development today, maybe even more so than frameworks. And they cripple the features of many of the files types they bundle. WebBundles fixes that.

jmull 6y ago

Thanks. That's all good. But I don't think this "...WebBundles just fix it all" is going to happen. I think it's going to be: web bundles is (yet) another option, with its own pros, cons, caveats, learning curves, migration challenges, support, etc. That's just how I see it, I know I can easily be wrong. If it takes off, we'll be able to measure its value by penetration. E.g., if it's being used on 1% of sites, that means it has some decent niche value. If it's being used on 10% and rising sites, we'll know it has really good value.

jiggawatts 6y ago

Explain to me why any of this is necessary once HTTP/3 is widely adopted? Isn't the whole point of HTTP/3 to "emulate" bundling without actually requiring content to be zipped up into a binary blob? Isn't it also quite good at caching, such as incrementally updating individual files without complexity? Isn't it also capable of pipelining a bunch of small logical files into a contiguous stream as-if they were in one big blob? Isn't the head-of-line blocking issue, which HTTP/3 solves, going to be a problem with monolithic web packages? What's next... WebPackage 2.0 with a yet another head-of-line-blocking-solution!? This all feels like the left hand not talking to the right hand at Google. It also feels like Google is perfectly happy to bloat web standards to the maximum extent possible given the size of their development team, permanently and irrevocably blocking anyone from ever again developing a web browser from scratch to compete with Chrome. Unless of course they can devote a few thousand man-years to the task. Which noone short of two or three companies can now. I've never even heard of this "problem" that Google is trying to solve, but clearly Google is pushing very hard for it to be solved... for some unstated reason. From the outside, this feels incredibly self-serving.

spankalee 6y ago
HTTP/3 is just HTTP/2 over QUIC, fixing head-of-line-blocking will help some, but... Having spent lots of time trying to optimize servers to correctly utilize HTTP/2+push, and building bundle-less deployments, not only is it quite difficult, it doesn't achieve the compression performance that bundling does. We measured ~30% better compression from a bundle over separate files. And I don't see this as bloating standards at all, but fixing a huge problem in current web development and paving a cow path. Bundlers are central to web development today, maybe even more so than frameworks. And they cripple the features of many of the files types they bundle. WebBundles fixes that.