Web Bundles (Web Packaging)

[FluorescentHallucinogen]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Bundles (Web Packaging)
• Specification or proposal URL: https://github.com/WICG/webpackage

Other information

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

It would be interesting to know an opinion in the context of Web Bundles (*.wbn files) as universal executable format for web apps.

[FluorescentHallucinogen]

@jyasskin @irori cc.

[jyasskin]

It probably is time to ask for a Mozilla opinion on unsigned bundles/packages, which I hope will be distinct from the opinion on signed packages 😅. We have an explainer for navigation to unsigned bundles.

There's also a plausible use case for use of unsigned bundles to provide a group of same-origin subresources for a page, which I don't have an explainer for yet.

I wouldn't claim that this is a "universal executable format for web apps" yet. It looks useful, and like it avoids many of Mozilla's concerns about signing, but there are still questions to work out.

[martinthomson]

Many of the concerns are alleviated, for sure. However, as it seems that the intent is to make the design here contiguous in many ways with the signed packages, the design choices here are very much influenced by signed packages.

We'll need some time to work through the design of navigation to unsigned bundles as I think that is central to this question more than a simple (ish) file format.

It's possible that there are different ways of approaching the problem that are less complex, for instance. Minting a new URI scheme is not something that is undertaken lightly.

cc @annevk

[adamroach]

@martinthomson --

We'll need some time to work through the design of navigation to unsigned bundles as I think that is central to this question more than a simple (ish) file format.

Is that a vote for defer?

@annevk -- You have any thoughts here?

[martinthomson]

I think that this is likely trending toward non-harmful in its current state, but we might still defer.

[annevk]

I looked into this a bit and there's a whole lot of complexity that I'm not sure is justified or is workable, e.g., WICG/webpackage#560. It seems this is very much in the prototyping phase still and the number of impacted specifications hasn't been quite realized yet. WICG/webpackage#551 is also curious. non-harmful seems like a reasonable starting point.

[est31]

Sadly, in recent years browser after browser have disabled xhr support on the file protocol (chrome in 2010, Firefox in 2019). Furthermore, many modern web features like es6 modules and wasm using separate files are intentionally broken. file:// as we know it is dying. Unsigned wbn files (loaded via file:// but now able to use the disabled features due to better cors support) could help counter this development.

• They would allow web development to happen without requiring web servers (usability hurdle for anyone who wants to distribute proposals to non-technical people e.g. via e-mail attachments) and only requiring build toolchains (already required anyways)

• They would allow documentation generation tools (which expect file:// to work) to use features like fetchagain (rustdoc for example is struggling with not being able to use fetch)

• Firefox's "save page as" feature could use it

• Documents like invoices can use it

wbn files won't become the executable format for the web as they lack data storage support. But they'd be the document presentation format for the web for stuff not served by web servers.

[adamroach]

Based on the conversation so far, I propose finalizing this as non-harmful, with detail of:

The mechanism as currently sketched out seems to provide potentially useful functionality for a number of use cases. This is a complex mechanism, and substantial detail still needs to be filled in. We believe the general intent of the feature is well-enough defined to designate as "non-harmful" at this time (rather than "defer"), although we anticipate potentially revisiting this decision as the mechanism is refined.

[annevk]

Thanks, I think that's reasonable. I'm still rather worried about the UI conundrum, but as you note we can revisit this.

[mnot]

I'm a little surprised that Moz thinks this is non-harmful.

Bundling is going to further incent developers to make sites where most resources are bundled together. This not only obviates a lot of the work the community has put into HTTP/2 and 3, it creates a situation where developers will be likely to create a bundle that's optimised for the browser engine with the largest market share, leaving others (including Firefox) in a position where their engine doesn't get content in the order most optimal to them.

[jkrems]

it creates a situation where developers will be likely to create a bundle that's optimised for the browser engine with the largest market share, leaving others (including Firefox) in a position where their engine doesn't get content in the order most optimal to them.

I think the opposite is the truth: Web bundles create an opportunity for dynamically composing bundles that are today statically concatenated which opens up the possibility to not only build one big bundle optimized for one browser. So in that regard, it's at worst something that doesn't regress compared to current bundling solutions.

[mnot]

@jkrems there have been many, many proposals that have offered opportunities that weren't realised when faced with the reality of how people actually deploy their sites.

[KenjiBaheux]

In practice, sites are being deployed with unoptimized (non native) bundles, quite often with IE-era polyfills instead of taking advantage of broadly supported standards in a baseline bundle for evergreen browsers. This status-quo is bad for users and for the web. As jkrems said, the static and opaque nature of non-native bundles limits the opportunity for automated improvements at scale.

In the cases where the non native bundles have been optimized for one specific browser, the market forces mentioned are already at play. What Web Bundle does offer is an opportunity to understand what a bundle is made of as well as the opportunity to optimize it (ordering, composing, formats, etc.) at serving time (either in realtime or as a preprocess step), thereby allowing other parties* to re-optimize bundles as necessary, or more likely by not requiring developers to manually manage such complexity in the first place.

*: Potentially, this is a role that CDNs could play. I'd be curious to hear your thoughts on this.

[yoavweiss]

@mnot - beyond what @KenjiBaheux & @jkrems said, I'm failing to find concrete examples of cases where the resource order that a browser needs to receive would be different between one browser and another. Yes, different browsers use different heuristics regarding priorities they send to servers, but that doesn't mean they want to receive different things. They just experiment with and land on different solutions to the same problem: maximizing UX by getting render-blocking resources first, then non-blocking in-viewport ones, then the rest.

If you have a concrete example of such ordering issues, it would be great to outline it so we can discuss it specifically.

But perhaps the difference in opinions here is stemming from different vision on how web bundles for subresources will be used. What I have in mind is developers using them in-lieu of the bundler output they use today, which is essentially a JS blob (containing both JS and non-JS resources). Talking to bundlers they are excited about this, which means there's a strong likelihood the tools will take advantage of this optimization. We can work with them to ensure that the tools e.g.:

• Don't intermix bundles of resources with different priorities and separate bundles of render-blocking or critical JS from bundles of follow-up functionality JS from bundles of in-viewport icons from bundles of out-of-viewport icons.
• When delivering JS, take into account the JS's dependency tree and ensure that the order matches the execution order of said JS
  • This will deminish the value of v8's streaming parsing and compilation and would bring similar advantages to engines which don't have those optimizations.
  • In return, v8 and other engines will gain the ability of "streaming execution"-like functionality - instead of waiting for the full bundle to download, engines can start executing JS resources as they come off the network
  • Caveat: In the case of ES modules, the above may require some indication to the browser about the dependency tree structure (depending on the typical tree structure), as well as other small changes to ES module execution semantics.

All in all, I believe WebBundles present an exciting opportunity to optimize resource delivery on the web for all browsers, and presents significant advantage over the status quo. Working with tool authors seems like a promising path to making sure WebBundles won't be abused in ways that provide a suboptimal experience to users.