Generic Bundling

Jeremy Darling jeremy.darling at
Fri Oct 11 07:19:57 PDT 2013

Oh, and server side support for asset bundling could be eased if your in
any language with an HTML pre-processor readily available.  Simply scan all
your script and link tags, add a ref tag to each, and spit out a zip in the
appropriate location.  Course it could also be part of your build tools if
your using them.

On Fri, Oct 11, 2013 at 9:17 AM, Jeremy Darling <jeremy.darling at>wrote:

> The way I read the proposal (and I could be wrong here), you would have
> copies on your server in the appropriate locations.  So I may have a /js/
> folder with all my core JS inside it, and a /vendor/*/ with each vendor
> package inside of it.  I could have multiple asset package's (one for my
> core, one for each vendor code, or maybe one for all vendor code), or I
> could simply have a single asset package referenced.  If the browser knows
> what to do with it all it will pull down the package files, extract it/them
> and use the code from the package.  If not it would call back to the server
> for each file that it needed on the page.
> Basically, here is my understanding in pseudo code (there may be typos
> below);
> <html>
>   <head>
>     <script type="text/javascript" src="/vendor/jquery/jquery.min.js"
> ref="/pkg/"></script>
>     <link rel="stylesheet" type="text/css"
> href="/vendor/skeleton/css/base.css" ref="/pkg/" />
>     <link rel="stylesheet" type="text/css"
> href="/vendor/skeleton/css/skeleton.css" ref="/pkg/" />
>     <link rel="stylesheet" type="text/css"
> href="/vendor/skeleton/css/layout.css" ref="/pkg/" />
>   </head>
>   <body>
>     <script type="text/javascript" src="/js/myLoader.js"
> ref="/pkg/"></script>
>     <script type="text/javascript" src="/js/mySupportScript.js"
> ref="/pkg/"></script>
>     <script type="text/javascript" src="/js/app.js"
> ref="/pkg/"></script>
>   </body>
> </html>
> My thoughts, after reading, are that there would be three requests or
> pushes back for /pkg/, /pgk/, and /pkg/ when
> the browser supported packaging.  If the browser didn't then you would see
> 7 requests to get the assets.
> Course, I could be wrong :)
> On Fri, Oct 11, 2013 at 9:07 AM, Russell Leggett <
> russell.leggett at> wrote:
>> On Fri, Oct 11, 2013 at 9:57 AM, Jeremy Darling <jeremy.darling at
>> > wrote:
>>> HTTP 2.0 will require changes to servers for it to work properly, it
>>> will also require that developers learn a bit more about the pipeline or
>>> rely on some vendor to implement the "smarts" for them.
>>> Asset Bundling on the other hand will provide a quick and easy
>>> transition for most development communities.  Compress everything, update
>>> your ref's and wait for the browsers to catch up, or for your server dev
>>> team to work out push.
>>> You could still push your asset bundle with HTTP 2.0 and achieve
>>> basically the same results as if you bundled all the assets and sent them
>>> down the pipe with HTTP 2.0.
>>> I don't see them as foe's or alternatives to one another.  Quite to the
>>> opposite, they seem to compliment each other quite well.
>> Well, just so I understand - let's say you have 100 JavaScript files you
>> want in your bundle. Can you explain to me the strategy for handling the
>> fallback unsupported case? Does the bundle contain module based code
>> assuming es6 and the fallback is all es5 code using traceur or something?
>> Just trying to get a vision for this.
>> - Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list