[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

[andrewstuart]

How about just shipping it with all the main presets all configured and built in?

Not even the need to understand what presets are, choose the presets, install the presets, diagnose the problems with the presets etc. Just make it work out of the box.

[thejameskyle]

Making it "work out of the box" is something we had before, and we watched as proposals changed and we blew through 5 major releases in like 6 months getting more and more complicated as we went.

On top of that it was only going to get worse as people were throwing proposals around left and right and we never were quite sure what a "sane default" was. We were never sure how to keep people on track with rapidly changing proposals.

The move to a completely configured Babel, meant a move from implicit behavior to explicit behavior. People are forced to tell Babel what they want out of it.

Configuration means explicitness, explicitness means safety.

[andrewstuart]

This strategy underestimates the cost and difficulty of configuration.

Hopefully the message that is coming through here is that configuring Babel is extremely hard and time consuming and error prone and is a massive, massive headache.

I am still right now trying to work out why async and await do not work after spending all day on it.

Probably for Babel experts configuration is easy and quick but for those who are not specialists in it forcing users down a configuration path is deeply, excruciatingly painful.

[pas]

They need a big getting started page and direct newcommers to it where they don't try to be clever, but directly list scenarios.

Or they (or you) could make a configurator (they already have a build-tool focused one, but they need one kind of like what jQuery has) on the website, where you can select your target browser version(s), and what features you want enabled. Bam. Magic! Here's a JSON file, put it into your project root.

Async/await, I'd just go with TypeScript and then transpile the ES6 to ES5 with Babel.

See: https://github.com/andrenarchy/jspm-typescript-es6-boilerpla...

[kevan]

>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.

I think this would be a great first step towards making startup for new users less painful. Or maybe making an onboarding process similar to `npm init`, where the user is walked through a series of questions about what they need for their project and the initial .babelrc is generated automatically.

[hzoo]

Yeah I think we can try adding something like that to the homepage.

npm install --save-dev babel-cli babel-preset-es2015

echo '{ "presets": ["es2015"] }' > .babelrc

echo "console.log(`1 + 1 = ${1 + 1}`);" > index.js

./node_modules/.bin/babel-node index.js.

I would link to http://babeljs.io/docs/usage/cli/ since users wouldn't get what babel-node vs babel is.

The init cli is certainly something we should do; I mentioned this in a comment below.(issue is https://phabricator.babeljs.io/T6956)

[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.

[thejameskyle]

It's not that the users should be protected from themselves, but that they should be protected from instability.

Proposals are constantly changing, and keeping a monolithic Babel on track with them without breaking things for users all the time is a difficult problem.

The configuration is more than just configuration, it's explicitness. It's telling Babel exactly what you want out of it. That way you never have to worry about changing behavior until you want to make the migration.

The situation is more nuanced than you are recognizing.

[andrewstuart]

>> but that they should be protected from instability.

Appropriate protection is a warning in the docs "this code might change when the spec is finalised".

Inappropriate protection is hiding those features away behind difficult-to-configure barriers making it only possible for experts to configure their systems to run it.

[thejameskyle]

We did have those warnings in the docs. I wrote those warning. No one paid any attention to them.

I hate to say it, but you really don't know what you are talking about.

[dang]

> I hate to say it, but you really don't know what you are talking about.

Please refrain from getting personal in arguments on HN, even though it's frustrating when someone doesn't know what they're talking about.

This comment would be great with just the first paragraph.

[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.