isiahmeadows at gmail.com
Mon Aug 17 22:27:29 UTC 2015
I agree that it could stand to wait. Also, for what it's worth, the WHATWG
loader spec is still a huge work in progress AFAIK.
On Mon, Aug 17, 2015, 18:02 Bradley Meck <bradley.meck at gmail.com> wrote:
> The timing and extensibility is too complex to easily fit into ECMA-262,
> see some things mentioned in https://github.com/whatwg/loader/issues/54 .
> I vote no for a few years at least.
> On Mon, Aug 17, 2015 at 4:58 PM, Jason Orendorff <
> jason.orendorff at gmail.com> wrote:
>> 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
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss