Repository navigation
How does the js polyfill work with ES6 modules? #252
Description
I think we can agree that one of the big motivators for the polyfill is that it will work in existing browsers. And existing browsers don't have modules. It feels like a bit of chicken/egg problem to me. I can imagine some dynamic js code generation will be necessary on client side which decides whether to use ES6 module syntax or transpile to ES5, but I don't know how feasible this is. Anyway, I don't really have an architecture in mind, so I'm wondering what are you guys thinking?
Activity
kg commentedon Jul 7, 2015
Performance/flexibility considerations aside, the simplest approach would be for the polyfill to just generate ES5 with wide compatibility in mind. You could go further and make it do feature detection to figure out whether to generate JS that uses ES6/ES7 features like modules or int64 as appropriate instead of just emulating them, but that's more of an improvement than a feature.
As far as I'm concerned modules aren't of much use to the polyfill, but you want it to interact well with consumers who want to import a WebAssembly module from ES6. That's a bit easier to tackle.
lukewagner commentedon Jul 7, 2015
Agreed with @kg that, when the containing app isn't explicitly using ES6 modules, the polyfill should just generate ES5 code for maximum portability, even if ES6 modules are natively supported.
An interesting question is what happens when the containing app is using ES6 modules and importing wasm modules. The challenge is to translate the fetch triggered by
importstatements. If there is no native ES6 support, we can just hook the wasm polyfill into an ES6 module polyfill, so no problem. Furthermore, it seems like native ES6 module support may not happen much sooner than wasm, so apps could just count on using both and falling back to the ES6 module+wasm polyfill if either was missing. As a last fallback, Service Workers would also allow interception and translation and are coming along nicely. (For a while I was holding out hope for the Loader API, but it seems farther off.)MikeHolman commentedon Mar 1, 2016
For the time being at least, we will not use es6 modules at all.