Generic Bundling

Russell Leggett russell.leggett at gmail.com
Fri Oct 11 08:05:39 PDT 2013


On Fri, Oct 11, 2013 at 10:19 AM, Jeremy Darling
<jeremy.darling at gmail.com>wrote:

> 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 gmail.com>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/jquery.zip"></script>
>>     <link rel="stylesheet" type="text/css"
>> href="/vendor/skeleton/css/base.css" ref="/pkg/skeleton.zip" />
>>     <link rel="stylesheet" type="text/css"
>> href="/vendor/skeleton/css/skeleton.css" ref="/pkg/skeleton.zip" />
>>     <link rel="stylesheet" type="text/css"
>> href="/vendor/skeleton/css/layout.css" ref="/pkg/skeleton.zip" />
>>   </head>
>>   <body>
>>     <script type="text/javascript" src="/js/myLoader.js"
>> ref="/pkg/app.zip"></script>
>>     <script type="text/javascript" src="/js/mySupportScript.js"
>> ref="/pkg/app.zip"></script>
>>     <script type="text/javascript" src="/js/app.js"
>> ref="/pkg/app.zip"></script>
>>   </body>
>> </html>
>>
>> My thoughts, after reading, are that there would be three requests or
>> pushes back for /pkg/jquery.zip, /pgk/skeleton.zip, and /pkg/app.zip 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 :)
>>
>>
Ah, ok, a little different than the way I read it, but I think you're
right. I've got to be honest. I wouldn't use this. The fallback case on a
large app would be such a tremendous http request fail (assuming HTTP 2.0
not in place). For it to be something I would really want to use, I guess I
would probably want to load two different sets of files - one for browsers
with module/bundling support and one for everyone else (fallback). The
fallback would have to be ES5 compatible code and would probably use
concatenation or an ES5 compatible loader.

So I guess, thinking about it, I think the major flaw with HTTP 2.0 server
push for me is not the technology itself, but how hard it would be to use
it with an *acceptable* fallback. Right now the code I write has a ton of
smaller files that uses a smart build to make a dependency graph and
smartly concat into optimal chunks, an ideal case for ES6 modules as its
already basically divided that way and already has fake import statements.
I could change the build so that it used server push instead, but the
fallback case would go horribly awry. I don't know, I guess I'll just have
to think about a way to make that work. There's probably a relatively easy
strategy.

Out of curiosity - does anyone have a good solution in regards to fallbacks
for modules? Using traceur and serving ES5/ES6 versions is what immediately
comes to mind.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131011/209f3694/attachment.html>


More information about the es-discuss mailing list