So the easier the build tools are to install and use, the better. Ideally, for common use cases, the end user will need to do precisely nothing apart from install the build tool to get basic and even advanced level usage out of it.
And Babel is one of the core parts of that build system. It compiles ES2015 code to ES5 that can be run on any browser.
Out of the box, Babel doesn't do anything. Literally useless by default. Want to do something? You MUST configure it. And of course that means you have to start learning how to drive and configure Babel.
The first step in learning a new system is the hardest and most confusing and most time consuming. To configure one tiny thing a vast array of questions come up. Am I really meant to do this? Should I be changing this setting? Why do I need to do this? What does it do? Am I breaking something? Are there more things to configure? Am I working with the latest information or has the system changed since the documentation I am reading? Why have I found three sets of conflicting instructions to do this configuration? And the biggest question of all - why do the instructions on this web page not match what I see on my screen? And then of course, "I've made the changes as instructed, why doesn't it work, what's wrong?". All these questions come from a hazy fog of ignorance of what the software is, how it holds together, what it's purpose is and why it works the way it does. You groan inwardly and sigh - fuck, how deep is this "simple" rabbit hole going to be? EVERYONE goes through this phase of learning a new technology.
If a build tool requires the user to make even one single configuration setting then they have imposed a huge learning cost on that user. Possibly many hours of time and possibly (even probably) failure in trying to reach their goal. For many users the cognitive load will be too high. And the user may not even succeed in doing configuration that the developers consider to be basic and trivial.
Conversely, if a build tool requires a user to configure *absolutely nothing*, then they have saved the end user hours and driven them to a "pit of success".
Experienced Babel 6 users will dismiss my assertion that configuration is hard. "It's easy!" they'll say. You change one file: .babelrc, npm install your presets, install your plugins and modify your update your webpack config and you're good to go! It's 60 seconds work so you are speaking garbage. "
Experienced developers forget how incredibly hard and time consuming and confusing it is for unexperienced users to do those 60 seconds worth of tasks.
So when Babel 6 decided that it would do nothing out of the box, it did the opposite of conventional wisdom in software usability, which is to include sane defaults that anticipate the most common use cases and provide them, ideally with zero requirement for setup and configuration.
Babel wants to exist, be seen and heard and talked about. But in fact it is plumbing that you should really never have to give a thought to unless you're walking a very unusual road. Babel's demands for you to configure it is like your taps in the kitchen needing you to get under the house with the wrench and hook up the hot water yourself, install a hot water tank, install solar panels and set the temperature in order to use it. Not stuff you should need to do. Babel should generally be neither seen or heard. The Internet should not be plastered with blog posts instructing you on how to configure Babel, some right, some wrong, some out of date, some conflicting. The developers should have configured it once, properly, so you don't need to think about it.
And finally, the cost to the Babel project itself is support issues and questions and problems from people who haven't managed to get things to configure, or didn't even know they were meant to configure - only that something isn't working. The Babel project is shooting itself in the foot and making work for itself. The Babel developers should always be focused on how to reduce and remove the need for configuration, to find effective ways to preconfigure, and to find ways to allow people to use Babel with ever less knowledge that it even exists.
OK I'm headed back to see how to configure Babel to use async and await. I really wish it was configured out of the box. What a waste of time.
P.S. and by the way I do know about Babel presets. That's too much configuration too. The right amount of configuration is none.