[loganfsmyth]

I totally agree that the initial user experience for Babel could use some work. We don't tend to do a great job of guiding users through initial setup. It absolutely needs work. I'd be curious to hear the author's thoughts on what we can do better in that respect, since "no config" probably isn't going to happen off the bat.

On the other hand, I don't feel that it's reasonable to assume that setting up a build system will be trivial. Jumping into ES6 isn't and shouldn't be a trivial decision, transpilation is a complex process with edge cases. That doesn't mean it should be a pain in the ass, and I don't want it to be, but it doesn't mean it will be instantaneous and easy. Users have totally different build targets (different Node versions, different browsers, some need IE8 support, some don't). Different systems need different levels of polyfilling and differing output syntax.

Enabling everything by default is one option here, but that encourages people to not consider how things actually work, which is rarely a good idea. It also assumes that adding complexity around knowing what to _disable_ is actually better, which I'm not convinced it is.

[jameskilton]

Isn't (or wasn't, when it was 6to5?) the entire point of babel to make jumping into ES6 as easy as possible for browser users? My expectation is that the default is "Compile my ES6 to ES5 that browsers can run", and anything further than that would be configurable.

[grrowl]

Unfortunately, because of browser support "ES5" itself is a moving target. With the release of Babel 6 they've dropping automatically polyfilling for Promises, so you'll need to include an additional polyfill or it will expect the browser supports it. Some setups use Babel to run on Node.js v4+ which supports most of ES6 natively.

There's no magical "ES6"-level of browsers which support all features of Promises, though[1]. Some products support IE11, some don't. Some only support the latest versions of Chrome and Firefox. Additionally, more people are using features not even in spec[2], known as "strawman proposals", some which are quite popular in real-life code examples[3]

Because of the moving targets on what Babel is transpiling from and to, they went for a "you decide" approach which promotes no particular level of "modern javascript" or "compiled javascript".

It's unfortunate they don't have `npm install --save-dev babel babel-preset-es2015` and "write `{"presets":"es2015"}` to a new .babelrc file" smack-bang at the top of the homepage though. The "handbook" links to a page of links, the "setup" page asks more questions than it answers. With modern Babel, no matter what build system, the above 2 steps are the same, and the 3rd is "add babel to your build system, or `npm install -g babel` and run that"

[1] https://kangax.github.io/compat-table/es6/ [2] https://babeljs.algolia.com/docs/usage/experimental/ [3] https://github.com/reactjs/redux/issues/226

[taion]

Exactly! Enabling unstable language features like decorators by default is the opposite of a novice-friendly decision, as is enabling by default features that require pulling in e.g. the Regenerator runtime.

The author of the post doesn't seem to understand that many of the transforms supported by Babel touch on proposals that are actually at various stages of being experimental or unstable, which actively should not be enabled by default for the sanity of users who don't know better.

Opting a novice user by default into a language feature that might well change is not a good thing! Otherwise we end up with something dumb like the legacy decorator transform, where people unknowing code against proposals that are liable to change under them.

Babel-5-stage-0-ese is not ES.next!

[andrewstuart]

>> actively should not be enabled by default for the sanity of users who don't know better

The idea that users should be protected from themselves isn't an effective one and is at the heart of the idea that Babel should do less and more should be configured in.

Nothing terrible will happen if a user uses a feature that is experimental or unstable. They might get to use it successfully however if it comes preconfigured. I can just update my code when the spec stablises.

>> the sanity of users

The sanity of users is broken by the myriad problems with Babel configuration.

[hzoo]

If we don't decide to include "everything" by default, we can work on better docs (help is appreciated in where that could be improved as well as contributors!), and create a better setup experience with something like a `babel init` command. We can also run that/error when a user tries to run babel without specifying a preset/plugin.

http://babeljs.io/docs/setup/#babel_cli

[gedy]

Main gripe a lot of people I know share with me is that Babel 5 was easier, and babel-node was useful out of the box. Now it feels like getting someone's dev style getting foisted on us to get something useful out of it..

[rattray]

> ...but that encourages people to not consider how things actually work, which is rarely a good idea.

I'd actually take the opposite position here: people should typically not have to consider how the tools they use work, until they need to go beyond the basics.

If all I want is "the latest javascript", I should be able to get it without pondering the genius of a library's creators.

[andrewstuart]

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?

[robzyb]

> I do think the kitchen sink should be included by default, even for experimental stuff. Optimisation and minimisation should be the expert case.

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.