ES6 Loader proposed changes

Brendan Eich brendan at
Thu Sep 11 15:51:31 PDT 2014

Ian Hickson wrote:
> 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...?

"Hook evolution" is fair -- first you'd do one class of loadables, then 
induct to a second and if you couldn't extend APIs compatibly, you'd 
have to do some forking. Perhaps not much. The path dependence cuts both 
ways: you may make the system strictly more complex in hindsight; you 
may OTOH bring along implementors and learn things via interacting with 
them and with developers over multiple releases that you couldn't learn 
trying to do it all up front in one big jump.

I'm an optimist, so I vote for smaller jumps, but whatever you can do, 
get implementors on board. Doesn't seem doable otherwise (or it might 
end up a near miss or oversold scenario-solution like appcache -- no 
offense, trying to learn from history in case it rhymes ;-). And you 
might well nail the ultimate system from a dead start without going 
through the smaller jumps, don't get me wrong. The odds are worse, and 
we won't know till implementors catch up, which could be a while.

The EWM "explaining the platform via ES-exposed primitives" doesn't work 
well in big jumps, since much of the system has been explained only by 
non-JS and leaky-abstraction (and legacycaller, etc. anti-JS 
abstraction) C++ implemenation code. Ideally, EWM adherents find the 
"narrow waist" of the existing system to cut across with low-level JS 
APIs that could be used to implement everything above with good 
performance. This is hard.


More information about the es-discuss mailing list