ES6 Loader proposed changes
ian at hixie.ch
Thu Sep 11 15:10:59 PDT 2014
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the es-discuss