Consider leaving out babel-preset-es2015 in development.

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]

Here’s my proposal.

By default we compile assuming the browser is evergreen. This gives us fastest build times and least mangled output.

We also add a middleware to Webpack dev server. It sniffs user agent.

If it detects an evergreen browser then nothing happens. Bundle is served as usual.

However if UA is outdated (or unknown) the server “downgrades”. Practically it means that we restart the server with full ES2015 preset. The rest of the current session will now be using it.

If you restart the server, it will start in modern mode again.

To sum up:

1. By default we use modern mode. Use case: normal development.
2. A request from an old or unknown UA “downgrades” us to compat mode with all transforms, and it stays enabled throughout the session. Use case: testing in older browsers.

I don’t know how “downgrading” would work. It would be neat to avoid restarting the server, and just swap out the Webpack compiler. I’m not sure if WDS allows this but we might want to have our own custom server anyway (WDS is a tiny wrapper over Express) so maybe it makes sense to do it manually.

Any exploration work is welcome here and will be most appreciated. I understand the first impulse is to “put a flag on it” but that’s not what we do in Create React App.

[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.