On Thu, 11 Sep 2014, Brendan Eich wrote: > > It may be that you have to keep compatibility, which means larger API > surface over time, new more-unified and old less-unified subsystems > coexisting. That's how the Web has grown in other areas. Original DOM > didn't reflect all elements; in the '90s things evolved in layers.
I don't really understand what this would look like for the ES6 loader. Would we have different hooks for each kind of module? Or...? > Nevertheless if you can't get implementors on side, that's a strong > signal. Indeed. I don't really mind either way, for the record; I really assumed (in part from talking with Chrome people and others in #whatwg) that this was an obvious win and would be uncontroversial, especially with the recent focus on explaining the platform via ES-exposed primitives. Obviously for me it'd be a lot simpler if we didn't integrate things like this; it would let me spec a dependency system people are asking for for subresources of HTML documents without having to worry about integrating with CSS and ES6. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
