Nope. You're the one advocating targeting a specific platform, and it's called Babel.
What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.
If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.
To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.
Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of
CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.
Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.
I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.
What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.
If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.
To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.
Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of
CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.
Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.
I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.