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.darl...@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 :) > > > On Fri, Oct 11, 2013 at 9:07 AM, Russell Leggett < > russell.legg...@gmail.com> wrote: > >> >> On Fri, Oct 11, 2013 at 9:57 AM, Jeremy Darling <jeremy.darl...@gmail.com >> > 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 >> > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
