Module import/export bindings
curvedmark at gmail.com
Mon Mar 16 06:21:03 UTC 2015
On second thought, this does seem to imply that polyfills can’t use the module syntax, which means they can’t use utility libraries written in module syntax, and, if you are writing a complex polyfill, managing dependencies requires ensuring correct script loading order (whether that means managing script element order or file concatenating order in a build step). Not to mention having to wrap each script in an IIFE.
This feels like being thrown back into the dark days, and I don’t think writing polyfills should be that different.
So now I have more questions:
1. When the environment you are trying to polyfill exposes the global object, should you use the module syntax?
2. When polyfilling the language’s standard library, should you use the module syntax? If so, how do you get hold of the global object?
3. If the answers to these questions are no, how do you use a library, written in module syntax, in the polyfill that can later be reuse by the project (without converting the library to script syntax and duplicate the code in the end of cause)?
> On Mar 16, 2015, at 11:56 AM, Glen Huang <curvedmark at gmail.com> wrote:
> Didn’t know about the service. It looks really promising. Thank you for letting me know.
> So you are saying polyfills should really be included as scripts and not modules? That makes sense.
>> On Mar 16, 2015, at 11:11 AM, caridy <caridy at gmail.com <mailto:caridy at gmail.com>> wrote:
>> correct, it is about evaluation.
>> yes, modules will have access to window, and any other runtime feature.
>> no, I don't recommend using modules to patch the runtime, features should probably be patched before attempting to load any module (maybe using FT polyfill service).
>>> On Mar 15, 2015, at 10:57 PM, Glen Huang <curvedmark at gmail.com <mailto:curvedmark at gmail.com>> wrote:
>>> My guess is that it’s for importing modules that expose objects via the global object (e.g., window).
>>> However I do have a question: is it possible for a module to access the global object without relying on the host environment?
>>> One use case is to polyfill the language's standard library. es6-shim uses a pretty ugly hack (https://github.com/paulmillr/es6-shim/blob/e17ca7ad73528261a3fc4af2ad71ebc3c8f84c0e/es6-shim.js#L76 <https://github.com/paulmillr/es6-shim/blob/e17ca7ad73528261a3fc4af2ad71ebc3c8f84c0e/es6-shim.js#L76>).
>>> I wonder what’s the most elegant way to do that?
>>>> On Mar 16, 2015, at 3:59 AM, Kyle Simpson <getify at gmail.com <mailto:getify at gmail.com>> wrote:
>>>> Thanks, all answers super helpful!
>>>> One last clarification:
>>>> import "foo";
>>>> This doesn't do any binding does it? AFAICT, it just downloads and runs the module (if it hasn't already)?
>>>> If that's true, what's the use-case here besides "preloading" a module performance wise?
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>>> es-discuss mailing list
>>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss