Generic Bundling

Jeremy Darling jeremy.darling at gmail.com
Thu Oct 10 18:28:02 PDT 2013


I understand g(un)zip is the de-facto standard, I would just hate to see
such a small detail overlooked at the end of the day when a one liner
pretty much covers it.

Oh, and I'll 2nd the "way nicer than any AMD solution".  This also keeps
readability in mind along with forcing declaration instead of allowing you
to loose track of dependencies accidentally.  I prefer to have page bloat
in dev form and compile down for production use only if necessary.

Course, that's two cents from a guy who usually hides in the corners on
this type of discussion.


On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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 <bruant.d at 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 at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131010/bd0bea32/attachment-0001.html>


More information about the es-discuss mailing list