Hacker News Reader

Comment by taion | Hacker News Reader

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!

View on HN

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

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.

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

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.

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

Reply on news.ycombinator.com