You are confining the problem in HTTP only scenarios while the solution provided by
<script src="lib/main.js" ref=”assets.zip”></script> can be handy/reused in offline packaged applications too so HTTP 2 might win on HTTP but it's not a general HTML App packaging option. I think FirefoxOS Apps might have something similar without even bothering the network stack, but then there apps are already packaged in a similar way so here would be the common bundle/package within the bundled FFOS App but others might reuse same logic too. @Jeremy, it does not matter much what browser prefers when the de-facto standard is to accept and support either deflate or g(un)zip so anything compatible with these two (basically same) algo woul dbe acceptable and easy to implement for everyone, am I correct? Back to the HTTP support, I would go for the possibility to bundle through CDN too which might penalize minor used libraries (like few of mines) but boost up most common scenario across websites or apps (thinking about Angular bundle, Ember bundle, jQueryUI bundle or ExtJS bundle, etc) Last personal thought: this is way nicer than any AMD solution I've seen, giving a real alternative to async modules too via script defer/async attributes without requiring boiler plates all over to include on demand. +10000 for that -1000 is worth my opinion ^_^ On Thu, Oct 10, 2013 at 11:22 AM, David Bruant <bruan...@gmail.com> wrote: > HTTP 2 is coming with a feature called server-push [1] which seems more > appropriate for this type of bundling. > In essence, when being asked for a webpage, the server sends the HTML page > as well as a bunch of resources (CSS, JS, image, whatever) in the same HTTP > response. These are individually decompressed and cached and available > handy when the HTML parsing requires fetching resources (lots of that can > happen in parallel I imagine, depending on the bundling). > Best of all, this is all seamless. Just keep writing HTML as you've always > had, no need for new "assets.zip$/lib/main.js" syntax. It keeps the HTML > decoupled from the "how" of resource delivery. > > Among other benefits [1]: > "pushed resources are cached individually by the browser and can be reused > across many pages" > => It's not clear this can happen with an asset.zip > > "by the time the browser discovers the script tag in the HTML response the > main.js file is already in cache, and no extra network roundtrips are > incurred!" > => Not even a need to load an additional asset.zip > > We can discuss the deployment aspects of HTTP 2 and whether Generic > Bundling as proposed can provide benefits before HTTP 2 is fully deployed, > but I feel the bottleneck will be the server-side engineering to bundle the > resources and this work is equivalent for both HTTP 2 and the proposed > Generic Bundling. > So HTTP 2 wins? > > David > > [1] http://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/ > > Le 10/10/2013 19:30, Jonathan Bond-Caron a écrit : > > About Generic Bundling in:**** > > https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/modules.pdf > **** > > ** ** > > <script src="assets.zip$/lib/main.js"></script>**** > > ** ** > > It could be reworked as:**** > > ** ** > > <link rel="loader" type="application/zip" href="assets.zip"> **** > > <script src="lib/main.js"></script>**** > > ** ** > > Simple pattern for packaging web apps where ‘assets.zip’ might be already > available.**** > > ** ** > > For remote fetching, I imagine it would block waiting for assets.zip to be > available. Could be solved with something like:**** > > ** ** > > <script src="lib/main.js" ref=”assets.zip”></script>**** > > ** ** > > Which would lookup <link rel="loader"> and match ref=assets.zip to > href=assets.zip**** > > ** ** > > Either way, I’m curious where the discussion is taking place, w3c? **** > > How does this fit with Ecmascript, System.loader?**** > > > _______________________________________________ > es-discuss mailing > listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
