Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does the js polyfill work with ES6 modules? #252

Closed
MikeHolman opened this issue Jul 6, 2015 · 3 comments
Closed

How does the js polyfill work with ES6 modules? #252

MikeHolman opened this issue Jul 6, 2015 · 3 comments

Comments

@MikeHolman
Copy link
Member

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?

@MikeHolman MikeHolman added this to the MVP milestone Jul 6, 2015
@kg
Copy link
Contributor

kg commented 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
Copy link
Member

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 import statements. 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 MikeHolman modified the milestones: Future Features, MVP Feb 24, 2016
@MikeHolman
Copy link
Member Author

For the time being at least, we will not use es6 modules at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants