Great job to everyone involved! I've been keeping up with the project since it was 6to5, and these changes look like they'll help clean things up quite a bit and hopefully reduce user confusion.
This change might a bit painful for some, but it had to happen. People shouldn't be relying on such early proposals in production.
I've been using @babel/preset-env since early on and it's superb. You just pick what platforms you're going to target, and you're pretty much good to go.
I'd suggest being a bit weary with automatic polyfills. It's very easy to start using every new feature out there only to have your resulting bundle balloon in size. Depending on the type of project, it might sometimes be better to be explicit about which features can be used, and manually importing those polyfills so you fully understand the price that you're paying.
There will probably be some people complaining about complexity and how certain things are still confusing. Although I would agree that there's still room for improvement, targeting multiple independent platforms just seems like it's a challenging problem to solve well. My experiences with cross-compiling native apps have been fairly limited, but when I've tried it I found it far more overwhelming when compared to setting up babel. Perhaps it's just my limited experience in the native space. Am I the only one, or have others shared similar experiences? If you disagree, I'd be very interested in reading about which tools you've used, and examples of ways in which you believe babel could be simplified or improved.
I've been doing two targets on my most recent projects... one for ES2017+ (async support in browser), and another for legacy (IE>=9). Which wasn't too bad for some things... for one of the projects, got to be too much, and I now just do a test for async, and if it fails redirect to "/legacy.html"
What browsers support generators, but do not support await?
The polyfill for async, converts those calls to generator functions - however i'm not aware of any browsers which support generator functions, but DO NOT support async/await
Every browser that supports generators is self/auto updating to a version that supports async. (Except maybe Safari)... in any case, that's where I decided to draw the line.
If it supports async, it stays on modern.html, otherwise it redirects to legacy.html. There's also the ability to do some server detection for what payload to deliver. It's just async support is the only feature I test for.
This change might a bit painful for some, but it had to happen. People shouldn't be relying on such early proposals in production.
I've been using @babel/preset-env since early on and it's superb. You just pick what platforms you're going to target, and you're pretty much good to go.
I'd suggest being a bit weary with automatic polyfills. It's very easy to start using every new feature out there only to have your resulting bundle balloon in size. Depending on the type of project, it might sometimes be better to be explicit about which features can be used, and manually importing those polyfills so you fully understand the price that you're paying.
There will probably be some people complaining about complexity and how certain things are still confusing. Although I would agree that there's still room for improvement, targeting multiple independent platforms just seems like it's a challenging problem to solve well. My experiences with cross-compiling native apps have been fairly limited, but when I've tried it I found it far more overwhelming when compared to setting up babel. Perhaps it's just my limited experience in the native space. Am I the only one, or have others shared similar experiences? If you disagree, I'd be very interested in reading about which tools you've used, and examples of ways in which you believe babel could be simplified or improved.