± > Because using a ZIP file is a bad practice we certainly should not ± > allow. As stated before, it will make the website slow [...] ± ± It seems what you're saying is that there are already superior ways to bundle ± JS modules and we don't need W3C to define another one. ± Perhaps—but this definitely has nothing to do with the ES module loaders ± proposal before TC39, which is bunding-system agnostic. ± ± We'll be working with the HTML standards folks to decide how the browser's ± default loader will work, but basically I expect it'll just fetch URLs. That means ± it'll support HTTP2 out of the box, if the server supports it, and "zip urls" if ± W3C decides to spec such a thing. Apps can of course customize the loader if ± they need some custom bundling scheme. So your beef is not with us or with ± the HTML WG but with the TAG—or wherever the work on "zip urls" is taking ± place these days (I really don't know).
I agree with you here. I think the word "allow" is an overstatement I didn't really intend. As I said further in the mail, a platform should always be flexible enough to make sure you can do something if you so want (i.e. with a Domain Controller). What I meant is indeed that the ZIP bundling is a measurably suboptimal practice overall and should not be promoted (i.e. made simpler than the state-of-art approach and/or mentioned as an acceptable solution). If ZIP URLs are found necessary for other use cases and are added to the platform, there's no reason to ban them from the Module Loader spec. But it remains that it's not a good practice in most cases. Bundling in general is not going to be a valid approach for any purpose related to efficiency soon (except maybe archive-level compression where grouping similar files may improve compression rate slightly). My point is that I'm not sure it's worth exploring bundling in the case of new standards that are going to be used in a future that someone can expect to come after HTTP2 birth. My intuition is that by the time every browser supports ES6, they will most likely support HTTP2 too - most of the already support drafts of it. It's not sure that most servers will support HTTP2 at that time, though. Therefore, I don't say this approach isn't worth exploring at all, but it's a temporary solution at best. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
