Standard modules - concept or concrete?

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Standard modules - concept or concrete?

Kevin Smith


Yes, like so:

    <script src="polyfillz.js"/>

Sure.   In a server environment, you'd have to do your monkey-patching and then load your "main module" dynamically through the loader api.

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Standard modules - concept or concrete?

James Burke-5
In reply to this post by Sam Tobin-Hochstadt
On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt <[hidden email]> wrote:

> On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith <[hidden email]> 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:

https://github.com/jrburke/carmino/blob/master/www/lib/IDB.js

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

https://github.com/jrburke/carmino/blob/master/www/lib/indexedDB.js

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.

James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Standard modules - concept or concrete?

Kevin Smith
Not sure how to answer your question exactly, James, but the takeaway is that under the current design, it is not sufficient to "import" global-object polyfills from the module that uses the polyfills.  Global object polyfills must be loaded in a *prior* compilation/execution cycle.

Bascially, you'll have to somehow (a) setup your global object with polyfills, and then (b) load your main module, with (a) and (b) happening in separate stages.

{ Kevin }

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Standard modules - concept or concrete?

Sam Tobin-Hochstadt
In reply to this post by James Burke-5


On Jun 20, 2013 7:53 PM, "James Burke" <[hidden email]> wrote:
>
> On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt <[hidden email]> wrote:
> > On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith <[hidden email]> 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:
>
> https://github.com/jrburke/carmino/blob/master/www/lib/IDB.js
>
> Asks for "indexedDB!", which is an AMD loader plugin:
>
> https://github.com/jrburke/carmino/blob/master/www/lib/indexedDB.js
>
> 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.

Yes, this will work fine. Loader hooks can explicitly add modules using the loader API, allowing them to polyfill in exactly this way.

Sam


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Standard modules - concept or concrete?

Kevin Smith
In reply to this post by Sam Tobin-Hochstadt


We think static checking for unbound variables is valuable, and
letting people write `console.log` without having to import anything
is valuable. Thus, option 3.


Another option would be to check unbound variables not in the linking phase, but immediately before executing the module body.  That would give us the advantage of variable checks, but also allow more flexibility when polyfilling or otherwise tweaking the global object.

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12