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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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). >> >> /caridy >> >>> On Mar 15, 2015, at 10:57 PM, Glen Huang <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Thanks, all answers super helpful! >>>> >>>> One last clarification: >>>> >>>> ```js >>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> <https://mail.mozilla.org/listinfo/es-discuss> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] <mailto:[email protected]> >>> https://mail.mozilla.org/listinfo/es-discuss >>> <https://mail.mozilla.org/listinfo/es-discuss> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
