Standard modules - concept or concrete?

James Burke jrburke at
Thu Jun 20 16:53:32 PDT 2013

On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt <samth at> wrote:
> On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith <zenparsing at> wrote:
>> I wonder, though, if this might create issues for polyfilling:
>>     // polyfillz.js
>>     if (this.Promise ===  void 0)
>>         this.Promise = function() { ... }
>>     // main.js
>>     import "polyfillz.js";
>>     new Promise();
>> This would refuse to compile, right?  We'd have to introduce all of our
>> polyfills in a separate (previous) compilation/execution cycle.
> Yes, like so:
>     <script src="polyfillz.js"/>
> Note that this is already the way people suggest using polyfills; see
> [1] for an example.

I have found that once I have module loading, I want the dependencies
to be specified by the modules that use them, either via the
declarative dependency syntax or via module loader APIs, and at the
very least, avoid script tags as the optimization tools can work
solely by tracing module/JS loading APIs. In this case, only the
"model" set of modules would care about setting up indexeddb access,
not the top level of the app.

Example, this AMD module:

Asks for "indexedDB!", which is an AMD loader plugin:

which feature detects and uses a module loader API to load a shim if
it is needed. So the "IDB" module will not execute until that optional
shim work is done.

I believe this will also work via the ES Module Loader API, but
calling it out just in case I missed something. I want to be sure
there are options that do not require using <script src> tags, except
maybe one to bootstrap a set of Module Loader hooks.


More information about the es-discuss mailing list