ES6 Loader proposed changes

Ian Hickson ian at
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 
> 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       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the es-discuss mailing list