4 ms·

> I very much want to see WebBundles succeed to solve many problems with asset distribution I’m wondering what those are. The use cases I’ve seen seem pretty t

by jmull 6y ago

> I very much want to see WebBundles succeed to solve many problems with asset distribution I’m wondering what those are. The use cases I’ve seen seem pretty tenuous to me (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.) I guess I may not know what the use cases are, but right now it looks like a complication with little upside.

prox 6y ago
Wondering the same thing. Can’t see any upsides for the user.
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 ago
  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?
  - jkrems 6y ago
    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.
  - RonanTheGrey 6y ago
    HTTP/3 still allows content blocking, and that's what they're trying to eliminate.
spankalee 6y ago
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.
untog 6y ago
> 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.
- jmull 6y ago
  I should be clear, that's a reaction to pages like this one: https://web.dev/web-bundles/ 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.

by jmull 6y ago

prox 6y ago

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

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 ago
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?
- jkrems 6y ago
  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.
- RonanTheGrey 6y ago
  HTTP/3 still allows content blocking, and that's what they're trying to eliminate.

spankalee 6y ago

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.

untog 6y ago

> 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.

jmull 6y ago
I should be clear, that's a reaction to pages like this one: https://web.dev/web-bundles/ 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.