3 ms·
I don't work on WebBundles, but I do work on open source web libraries, used by web developers, who often struggle to tie together tools to make up for the lack
by spankalee 6y ago
I don't work on WebBundles, but I do work on open source web libraries, used by web developers, who often struggle to tie together tools to make up for the lack of asset bundling in the web. I care very much about this feature as a way to reduce complexity and friction for developers, fully unlock new web features, and improve UX via fast asset loading and better caching.
And I'm not making a "claim" out of thin air. The WebBundles spec is available for anyone to look at: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...
WebBundles plug into the exiting request/response flow and allow a browser to fetch a response from the bundle instead of the server: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#name-load-a-response-from-a-bund https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...
It's effectively serializing a HTTP/2 stream. A browser doesn't have to fetch from the bundle and can fetch from the URL directly as well. Any processing currently done at the request/response level, like blocking, is still done on the request/response level.
There is an objective truth here that is not subject to conspiracy theories about the intent of Google.
WebBundles do not prevent content from being modified, and does not make web sites a "black box". That's just FUD, and I challenge you to point to where WebBundles do any such thing.
WebBundles are an archive format with an easily parsable index, and where it's easy to read individual files based on their offset in the bundle. The contents of WebBundles are individually processed, individually addressed by URL, individually populate the network cache.
If you have any evidence to back up your description of WebBundles as a black box, please provide it, because the fact on the ground do not support that assertion, and the article in question doesn't even directly claim that, even though it sneakily skirts around the issue by comparing bundles to PDFs. PDFs aren't modelled as a bundle of several responses, so the comparison is flat out wrong.
- RonanTheGrey 6y agoOk. Let's take your claim at face value. Can you explain how to accomplish content blocking with WebBundles? For example, adblockers?
- spankalee 6y agoThe work exactly the same. They don't even need any modification, as far as I understand. That's what I'm trying to point out by saying that WebBundles adhere to the current request/response model - they just preload a bunch of responses so you don't need the network round-trip. See the section I already linked: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#name-load-a-response-from-a-bund https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle... An extension that can modify requests and responses still can with bundles. In fact, it should be easier to identify and block individually address resources out of a WebBundle vs the transpiled bundle out of WebPack, et al.
- Vinnl 6y agoJust coming across this now, but since you seem to know a bit about this: can a tracker blocker prevent the preload requests from being sent in the first place, or alternatively, is it the case that the preload requests do not allow whoever initially serves up that content to track who has been loading it?
- RonanTheGrey 6y agoThis seems like an advanced form of what service workers do, or am I misunderstanding? Provided that adblock/content block functionality wouldn't be impacted, I can provisionally get behind this. It would certainly make my life as web developer easier.
- nitrogen 6y agoOne of the reasons to block content selectively is to save bandwidth on metered connections. Does a WebBundled site have to also provide separate resources, or is there some way for this bandwidth to be saved for those who need to save bandwidth?
- justsee 6y agoAgain, I did not state "WebBundles = a blackbox". That is your misinterpretation of my comment which I took the time to clarify: "I am hardly claiming any one initiative takes us straight there [to a black box of the web]". I was extremely clear on that, and further explained that we must consider Google's pattern of behaviour and commercial interests here – not one specific action. Ignoring my good-faith clarification you seemingly continue to suffer this misconception – that I asserted something I didn't ("back up your description of WebBundles as a black box"). You may be more interested in engaging with and refuting arguments based on a convenient misconception, but I really am not. For anyone seriously interested in this topic from the perspective of the open web and content blocking, the blog author summarised his concerns in a Github ticket [1]. (The responses throughout the Github issue reflect a similar strategy of a 'fingers-in-the-ears, everything is fine, what are you talking about' approach) [1] https://github.com/WICG/webpackage/issues/551#issuecomment-618776153 https://github.com/WICG/webpackage/issues/551#issuecomment-6...
- rektide 6y agoYou've held to a strongly combative & in my opinion fairly arrogant/dismissive close minded outlook in the dozens of comments you've posted in this thread. It's frustrating having to cope with such a lopsided one-dimensional perspective that injects itself everywhere. I feel like you have overrun & dominated every single thing anyone else has offered. I see that you think this is a bad spec, but you don't seem to acknowledge comprehend or grasp that a lot of people want this for really good & wholesome reasons. Signed exchanges for instance are absolutely critical in allowing users to share content with each other while offline, which has radical & excellent potential.
- justsee 6y agoIt looks like you've responded to the wrong thread. (I posted one comment on this article, and a few follow-up comments to people who engaged with it.)