I see and I agree, this might cause huge different resulting in a feature detection mess.
Another possibility mentioned in the first post might be to have a unique link such <link rel="package" name="my-assets" type="application/zip" href ="assets.zip"> reusable later on through script tags, as well as images, css, svg, anything that requires that bundle and not only scripts. <script src="my-assets/js/myfile.js"></script> <img src="my-assets/images/img.png"> good "packaging" practices will be the same but when there is a link rel package with a name (title?) the UA might decide to fetch from that assets.zip instead of the url and ignore such assets.zip file otherwise ? Not such huge win for JS only but more generic packaging/bundling-together solution (that I agreed shouldn't have been discussed here since here we talk about ECMAScript only :D) Ph well, it was good to dream for few hours :-) On Sun, Oct 13, 2013 at 5:25 AM, Brian Kardell <[email protected]> wrote: > > On Oct 13, 2013 4:40 AM, "Andrea Giammarchi" <[email protected]> > wrote: > > > > > > On Sat, Oct 12, 2013 at 12:07 PM, Brendan Eich <[email protected]> > wrote: > >> > >> > >> However, Russell's counter-argument that fallback in older browsers to > loading lots of little files, request by request, from the server directory > hierarchy, may be too painful, reducing the value as a migration technique. > > > > > > this is what happens today with external CDN scripts and/or AMD like > solutions regardless ... if these are not bundled all together, isn't it? > > To me at least, the primary difference there is that in that case it is in > the authors hand whereas native feature support is in the hands of the user > agent, creating a potentially huge and unmanageable perf delta in the > short/medium term. >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
