Having a simple general purpose import seems a good enough goal to me. Use if or switch for conditional. Use try/catch/finally for error handling. Make everything load on first call and its lazy enough.
I'd extend it to loading other content-types though. If you want to import Coffee or JSON or XML it should be the same. If it's not JavaScript expose it as a stream and throw an error so alternate means can process it. Maybe implement it as an object that could be modified or inherited to leave it easily extensible. Thanks, Michael McGlothlin Sent from my iPhone > On Aug 17, 2015, at 4:58 PM, Jason Orendorff <jason.orendo...@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 > anyway. > > What do you think? > > -j > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
