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 <[email protected]> wrote: > > inline > >> On Mar 16, 2015, at 2:21 AM, Glen Huang <[email protected]> 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 :) > > /caridy _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
