| OP here. Simplification, preconfiguration, removing of the need to configure. If these were major project goals then the developers could be reminded of them every time they implement something. If a developer implements some new feature that requires (yet more) configuration then other project developers can remind them "hey was there any way you could have done this without config, or built the config in?". I do think the kitchen sink should be included by default, even for experimental stuff. Optimisation and minimisation should be the expert case. Maybe the kitchen sink costs are size of executable or performance of compiled code but I'd gladly pay that price for something that actually instantly works without always expecting to descend into configuration hell. Consider async/await. Why not include it fully configured out of the box? Right now I am sitting here wasting my Easter public holiday trying to get async/await to work - it still does not. "ERROR in ./app/components/Kernel/KernelFiles.jsx
Module build failed: SyntaxError: C:/Users/andrewstuart/devel/desktop/app/components/Kernel/KernelFiles.jsx: Unexpected token (253:17)" async/await are a great idea and developers will want to use them. Who cares if the standard is not yet ratified, why does that mean I should live with the cost of trying (unsuccessfully) to configure it? Why didn't the developers do it? >> I don't feel that it's reasonable to assume that setting up a build system will be trivial. Absolutely correct, and that's the precise reason why projects like Babel should do their utmost to make it as trivial as it possibly can be. >> Enabling everything by default is one option here, but that encourages people to not consider how things actually work This isn't a good enough reason to force me to do configuration. I really want to defer the need to know how things work as far as possible into the future unless I really need to know it now. It's not that I want to be ignorant, but right now I am focusing all my learning effort on programming my application, and how the language works, and how the libraries work. Do I really need to be forced to understand how Babel works too? I'd prefer not to unless that learning directly gets me some outcome. >> It also assumes that adding complexity around knowing what to _disable_ is actually better, which I'm not convinced it is. Yes but better to invert the formula so that configuration is a process for experts to disable functionality in order to optimise rather than forcing beginners to enable. Also, don't you Babel developers find you have to spend time constantly diagnosing configuration problems and errors? |
A common theme in the counter-argument is that developers should be aiming to get Babel to some "ideal state" which is neither zero-config or full-config.
I'm not ES/Babel expert, but I think that's a reasonable point.
HOWEVER, I strongly feel that it is easier to get to this "ideal state" if you start with a most-uses-cases config. It's always easier to optimise from something that works, instead of trying to optimise from a broken state in the way that Babel now ships.