4 ms·
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 trans
by jkrems 6y ago
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.
- jiggawatts 6y agoI'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?
- jkrems 6y agoAFAIK 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.
- RonanTheGrey 6y agoHTTP/3 still allows content blocking, and that's what they're trying to eliminate.