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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
