Consider leaving out babel-preset-es2015 in development.

[kasperpeulen]

I think I have suggested this before, but I never saw anything that convinced me that this is a bad idea.

It is great that for production that IE and other older browsers are supported, but just for development, I like to have a super fast rebuild. And I like to debug code that is close to my own source.

So why would we enable all of the plugins of babel-preset-es2015, if the browser we develop in support ES6 syntax natively? I think the only exception is if you develop in IE11 on windows 7. But I think a good estimation would be that 99% of the people develop in Chrome, Firefox, Edge or Safari.

Now it happens to be that those browser support ES6. So I think it would make sense to not use babel-preset-es2015 in development. The only plugin you need is babel-plugin-transform-es2015-modules-commonjs as the import spec is not yet finalised and implemented in browsers.

I have been trying that in an eject. And it seems much faster on larger apps. And because the lack of source-map support, it does help with understanding where the error is located.

[gaearon]

I actually don't think this is a bad idea. I'd like to hear more opinions about this.

[dralletje]

Let's try to figure out how much the speedup is, and if Chrome really supports all things that babel-preset-es2015 supports :D

[trueadm]

An argument could be had here to let the user define the device/environment versions like how Bublé does (@Rich-Harris). This is what my company have done with many of its tools – as I agree, es2015 is overkill for people that don't need it.

[aarondancer]

I'm thinking that it should utilize a babel preset that only transforms features that aren't yet implemented in most modern browsers. While Chrome has almost all of the ES2015 features implemented, Firefox 50 and and Safari 9 are still missing some.

This preset would be updated as the browsers implement the missing features.

[Dajust]

@dralletje I think chrome does, while safari seems to be leading 💃
http://kangax.github.io/compat-table/es6/

[hzoo]

@gaearon currently the object rest spread transform requires the destructuring transform so you'll need that too.

@aarondancer yep that was what babel/babel#3476 is about. I've thinking about just making a new repo so people can contribute more easily (if anyone has interest in helping out with that effort).

[sh1989]

Do we have some timings to demonstrate the improvement that we're talking about here?

My concern is simply that if React supports Browser x, then from a "no surprises" point of view, I would expect a user to be able to develop in that browser. Some enterprise environments are still locked down to less modern browsing experiences.

[gaearon]

To be more clear about project philosophy, if we can do something that significantly improves the workflow of 90% users at the risk of making the tool less viable for 10%, I think it’s OK for this project. It is meant to be opinionated, that is the value proposition. So the question is if the improvement to the workflow is truly significant.

[oshalygin]

I would be curious to see what the performance/reload reduction would actually be. as @gaearon mentions, is the improvement significant?

[aarondancer]

I was curious about the performance improvements, so I removed the ES2015 preset from one of my larger projects and put in a handful of plugins to handle the unimplemented features.

Initial build time: 23.6s -> 7.3s
Incremental build time: 7.8s -> 3.6s

Note: this wasn't a project utilizing create-react-app, so your results may vary.

[kasperpeulen]

tldr;
Given that babel-preset-es2015 would be replaced with babel-plugin-transform-es2015-modules-commonjs and babel-plugin-transform-es2015-destructuring

• Chrome 52 and Safari TP will work the same as they do now (if I don't miss something)
• Firefox and Edge do support very much babel-preset-es2015 features, but miss a couple less known ones.

---

I have been looking at http://kangax.github.io/compat-table/es6 a bit.

Safari:
Safari 9 support 53% of ES6. That is clearly not enough, but Safari 10 (which is in beta) supports 99% of ES2015. I read that Safari 10 will be released somewhere this fall. I was trying out Safari TP today, and it has actually very good developers tools. It actually seems like a pretty much direct copy of what Chrome has (even the UI). Reminds me of this quote of Steve Jobs hehe:
https://www.youtube.com/watch?v=CW0DUg63lqU

But all in all, leaving out babel-preset-es2015 in development, means that if you develop a create-react-app in Safari, you need to download Safari TP, which I think is reasonable.

There is one thing that Safari doesn't support (and Babel does), and that is that is doesn't throw an error if you do an assigment in a for ... in statement:
http://kangax.github.io/compat-table/es6/#test-miscellaneous_no_assignments_allowed_in_for-in_head

None of the modern browser support this, is this because this would be a breaking change? Anyway, it doesn't matter, as in an create-react-app environment, doing an assignment in a for ... in statement, causes a compile time error.

Chrome:
Chrome 52 has the same story as Safari TP, expect that it also doesn't support Array.prototype.values. I tried this in a create-react-app, but doesn't seem to work with babel-preset-es2015 included either. Is this a bug? I can only get this to work in a create-react app, if I include import 'babel-polyfill'; to index.js. Not sure if this is the expected behaviour.

All in all, for Chrome 52 and Safari 10/TP, it seems that indeed, babel-preset-2015 can be replaced without problems with babel-plugin-transform-es2015-modules-commonjs and babel-plugin-transform-es2015-destructuring (as @hzoo suggested).

Now for Firefox and Edge 14, it is a little bit different story. Firefox 50 supports 92% and Edge 14 supports 95%. There are quite a few things that babel supports and those 2 doesn't support yet, or only partly supports, or support using a flag.

Both Firefox and Edge doesn't support all well known symbols:

• http://kangax.github.io/compat-table/es6/#test-well-known_symbols

Edge supports all, but one with a flag, firefox doesn't support a couple that babel does support:

• http://kangax.github.io/compat-table/es6/#test-function_name_property

Firefox doesn't support two for ... of features and a static array method:

• http://kangax.github.io/compat-table/es6/#test-for..of_loops
• http://kangax.github.io/compat-table/es6/#test-Array_static_methods

Edge doesn't support:

• http://kangax.github.io/compat-table/es6/#test-Date.prototype[Symbol.toPrimitive]

Those doesn't seem to well known babel features, but yes, it seems a bit odd that they won't work in development on Edge and Firefox and do work in production.

[hzoo]

I tried this in a create-react-app, but doesn't seem to work with babel-preset-es2015 included either. Is this a bug? I can only get this to work in a create-react app, if I include import 'babel-polyfill'; to index.js. Not sure if this is the expected behaviour.

@kasperpeulen real quick, babel only transforms syntax and doesn't automatically polyfill - so things like Array.prototype.values, Promise, etc like mentioned. The options are to use your own polyfills, babel-polyfill, (or if making a library use transform-runtime)

[kasperpeulen]

@hzoo Okay, interesting, but then, as create-react-app is for apps, would it makes sense to add import 'babel-polyfill' to index.js in the create-react-app template?

[hzoo]

I think this was discussed in other issues - #125, #269, so I guess it depends on what should be included (maybe don't want to include all of the polyfill, just part of it).

[gaearon]

ES6 polyfills are large. We only polyfill Promises and generators. The rest it up to the user.