Personally, I love the concept of <script src="lib/main.js" ref=”assets.zip”></script> since it allows backwards compatibility if the client's browser doesn't support packaging. Older browsers would simply make the request for lib/main.js while newer browsers would await assets.zip and then load lib/main.js
The part I would be concerned about (maybe without reason) is compression algo utilized. There are enough API's in place that allowed browser vendors to simply pick their favorite and move forward as is. The last thing I want to have to do is embed my cab, zip, lz, 7z, ... file into my header to support everyone's flavor of compression. - Jeremy On Thu, Oct 10, 2013 at 12:30 PM, Jonathan Bond-Caron < [email protected]> wrote: > 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 list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
