dherman at mozilla.com
Tue Aug 18 18:36:27 UTC 2015
The `System.loader.import` feature isn't ready for stabilization yet, and
is blocked on a few other pieces of the Loader design. The concerns you
mention are definitely important and we're working on them in the Loader
spec, but no need to rush something through before it's ready. Over time,
we can definitely uplift aspects of the Loader spec into Ecma-262.
I'm working on a roadmap for the Loader spec to clarify the bigger picture.
Right now I've just got a skeletal dependency graph but I'll be fleshing it
out with some text to explain it better:
On Mon, Aug 17, 2015 at 2:58 PM, Jason Orendorff <jason.orendorff at gmail.com>
> The ES6 module system is taking a real beating in the comments section
> here: https://hacks.mozilla.org/2015/08/es6-in-depth-modules/
> People are concerned about things like:
> - There is no standard way to load any modules at all in the browser.
> - There is no standard way for a module to load other modules later
> (lazily, for faster initial load times).
> - There is no standard way to conditionally load modules.
> - There is no standard way to catch errors when module loading fails.
> There's a planned feature that addresses all these use cases:
> `System.import(moduleSpec, referrer)`.
> It's possible to make minor changes to HostResolveImportedModule and
> then specify `System.import` in terms of that. It could ship in the
> existing compilation-plus-polyfill module system implementations (like
> webpack) immediately. And it'd be fully compatible with the coming JS
> Loader Standard.
> Arguably something this fundamental to module usage belongs in ECMA-262
> What do you think?
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss