Hacker News Reader

Wondering the same thing. Can’t see any upsides for the user.

Disclaimer: I work on asset bundling at Google, but unrelated to Chrome's work on web bundles.

One problem with asset distribution is that bundling (good transfer compression, efficient full download) and fine-grained loading are fundamentally at odds. Both Google and Netflix depend on dynamically combining chunks into responses today. Web bundles makes this possible using platform features and potentially also adds proper cache invalidation on top of it.

It's not quite there in the current specs but being able to send ES module graphs in web bundles does have properties that are hard to replicate without it. This isn't really related to users sharing URLs, it's more about the behind-the-scenes of loading assets for a page that got loaded using a traditional URL.

I'll ask the same question as I did above: Explain to me why any of this is necessary once HTTP/3 is widely adopted?

Doesn't it already solve all of these issues, and head-of-line-blocking as well?

HTTP/3 still allows content blocking, and that's what they're trying to eliminate.

AFAIK HTTP/3 still only has header compression and does nothing for cross-resource compression. So I'm not sure how it relates to this?

I can see ways to model this kind of behavior on top of individual requests but it'd likely be even more complicated than it already is with web bundles. E.g. telling the browser that certain resources shouldn't be fetched because they'll likely be pushed because of a different pending request is super awkward without a "resource bundle" abstraction.

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.

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.

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.

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.

> people don’t want to send web bundles to each other. They want to share a link. They don’t want alternate transports in general, really, or the complexities that come with that.

Arguably "people" don't even want HTTP, either. They don't want any technical feature, they want the things they can do with that technical feature. You're right that they want simplicity, but Web Bundles done right should be very simple to the end user.

Just a random example that comes to mind: I want to share a number of photos with someone. A web bundle could very easily group those photos together along with a quick webpage showing thumbnails, selection etc. without ever having to involve uploading photos to a remote server. That seems like a really interesting possibility to me.

I should be clear, that's a reaction to pages like this one:

https://web.dev/web-bundles/

There are similar ones.

These are suggesting people want to share or access web sites in some other way than links. I don't think that's true in any significant way.

> ...they want the things they can do with that technical feature...

I agree. But the problem with all of the alternative transport scenarios is they have the user managing transport through some additional actions on their part. People couldn't care less about HTTP. What they like about it is they click/tap or copy/paste a link and that's it. Additional steps, like going through a specialized UI to share files via bluetooth is not going to interest very many people. That web site actually suggests people may want to share/access their website through the sneaker-net. That's just not a very important scenario.

To take your photo sharing example. That could be done using a web bundle. But it could be done in a variety of ways that would look the same from a user perspective. Keep in mind a network (with servers) is needed to share the data, whether there's a web bundle or not. So the remote servers are there, regardless.