bradley.meck at gmail.com
Tue Aug 18 17:45:35 UTC 2015
This would assume they can support the transformation hooks to do things
like load coffeescript etc. right now, which is the main contention point.
On Tue, Aug 18, 2015 at 12:43 PM, Jason Orendorff <jason.orendorff at gmail.com
> On Mon, Aug 17, 2015 at 9:50 PM, Bradley Meck <bradley.meck at gmail.com>
> > I think we all want to find a good solution to creating a Loader for ES6
> > modules. I would follow WHATWG's Loader if you want to participate. There
> > are a surprising number of considerations, particularly due to existing
> > bases.
> I'm aware of the considerations. I helped Dave Herman hash out the
> Loader design.
> The opportunity here is that we can specify System.import() now
> *without* having to solve all those considerations overnight.
> There is nothing stopping us. We have the primitive. We have standard
> syntax that uses it. All we have to do is say "...and here is a
> standard API that exposes the same primitive".
> Then JS programmers will have a way to call that primitive
> procedurally, something they now lack.
> This proposal is *not* for the immediate benefit of browsers, which
> indeed need to wait for Loaders and/or <script type="module">. But
> implementations that already support ES6 modules, such as
> Babel+webpack, could implement this tonight. They've already got code
> to load modules; they expose it via nonstandard APIs; the additional
> effort to provide System.import() would be minimal. Then people
> writing ES6 code today would have a complete standard module system to
> code to and use.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss