On Fri, Oct 11, 2013 at 10:19 AM, Jeremy Darling <jeremy.darl...@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.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 :) >> >> 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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
