Module import/export bindings
curvedmark at gmail.com
Wed Mar 18 06:07:42 UTC 2015
Thank you for showing me the bigger picture.
If there ever come a day when web/stdlib APIs are exposed as modules, then polyfills are themselves modules.
But if modules aren’t supposed to patch the runtime as effectible scripts do, then I have the same question as Kyle does, what’s the use case for importing a module without binding it to an identifier?
> On Mar 17, 2015, at 12:37 AM, caridy <caridy at gmail.com> wrote:
>> On Mar 16, 2015, at 2:21 AM, Glen Huang <curvedmark at gmail.com> wrote:
>> 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.
> Glen, I said "I don't recommend it" (as my personal opinion), I never said it can't be done. The reality is that we don't know yet how are we going to introduce new features after modules become ubiquitous, maybe new features will come in the form of modules that you have to require, and to polyfill new features you just need a synthetic module that exports the right API, we just don't know yet. But polyfills, in their current state, are simply runtime patches, and using them should NOT require a module system as today, they are effectible scripts. That does not means you can't write polyfills using ES6 syntax, you can, just transpile them to scripts :)
More information about the es-discuss