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

Framework: Investigate using babel-polyfill #2360

Closed
gwwar opened this issue Jan 12, 2016 · 10 comments
Closed

Framework: Investigate using babel-polyfill #2360

gwwar opened this issue Jan 12, 2016 · 10 comments

Comments

@gwwar
Copy link
Contributor

gwwar commented Jan 12, 2016

Currently babel-runtime does not polyfill all ES6 language features, so we sometimes run into bugs when we expect certain prototype methods to be available.

For example String.prototype.startsWith is unavailable in IE11

@blowery
Copy link
Contributor

blowery commented Jan 13, 2016

Currently babel-runtime does not polyfill all ES6 language features...

Half true. We're not actually using babel/polyfill, we're using the babel/runtime with webpack, which only polyfills non-prototype things. So we get Map and Set and Object.assign, but not things on String.prototype like startsWith.

@blowery
Copy link
Contributor

blowery commented Jan 13, 2016

The concern in the past was the size of the full polyfill. Given the number of crasher bugs that have slipped through on various platforms because of confusion about what's available and what's not, I think we should bite the bullet and pull in the polyfill.

@gwwar
Copy link
Contributor Author

gwwar commented Jan 13, 2016

Half true. We're not actually using babel/polyfill, we're using the babel/runtime with webpack

;) was the title of this issue not clear enough?

@blowery
Copy link
Contributor

blowery commented Jan 14, 2016

😺

@blowery
Copy link
Contributor

blowery commented Jan 14, 2016

I have no idea what I thought I was adding when I wrote that original comment. Total reading comprehension fail on my part. Sorry about that. :person_frowning:

@gwwar
Copy link
Contributor Author

gwwar commented Jan 14, 2016

No worries 👍 Thanks for adding notes on the size concerns.

@rralian
Copy link
Contributor

rralian commented Jun 18, 2016

Minified and gzipped it looks like it's 32k (grab the polyfill here to see). That would bring our build.js from about 170k to about 200k. It's not insignificant, but I'd pay that price to enable the features and avoid the problems we've run into. Would be great if we could include it dynamically based on feature-sniffing though. Not sure if that's a thing.

@mtias I think you are the filesize arbiter and czar. What do you think?

@stale
Copy link

stale bot commented Jan 11, 2018

This issue has been marked as stale because it hasn't been updated in a while. It will be closed in a week. If you would like it to remain open, can you please comment below and see what you can do to get things moving with this issue? Thanks! 🙏

@gwwar
Copy link
Contributor Author

gwwar commented Jun 15, 2018

Fixed in #25419 by @jblz

@blowery
Copy link
Contributor

blowery commented Jun 15, 2018

That would bring our build.js from about 170k to about 200k.

oh the good old days

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

No branches or pull requests

3 participants