Hacker News Reader

Comment by Gudahtt | Hacker News Reader

>However, I am one of those people who think that Babel6 is terrible, that it "broke the web", and it marked the beginning of the entire JavaScript fatigue era.

Granted, I wouldn't consider this a personal attack. But it definitely qualifies as negative and nonconstructive.

I literally can't imagine how one could argue that they "broke the web"; that's completely ridiculous. If the migration path wasn't explained very well, why not say that? Or if you find configuring the tool confusing, and would prefer it to have "sane defaults" in the absence of configuration, why not say that? Instead of calling it terrible and blaming it for the "javascript fatigue era".

They realized that what had once been "sane defaults" were no longer sane, so they removed them. That's it. I can accept that there were legitimate complaints to be made, but the hyperbole and general negativity was over the top on this one.

View on HN

The migration path wasn't explained at all.

This is fine, if there would be a nice documentation for new version. There wasn't, except for some scattered blog posts.

This is fine, if new version offered some exciting new features or simplified thing a lot. But no, everything became significantly more complicated.

This is fine, if Babel was a production library packed into final build, and modularity is necessary to save precious bytes from web-transmitted JS. But no, it is a development tool. Nobody cares about its size or one-size-fits-all.

I just don't understand. What is the use case that required such a big sacrifice?

No arguments about the poor documentation on how to migrate; that's fair.

But we're straying from the point I was trying to make; your feedback was overly negative and hyperbolic.

We're all guilty of doing this at times, but it's not a constructive activity to engage in. I don't fault you personally for making one overly negative comment, but en masse it's harmful for the community.

To address the other points you raised; I personally found Babel 6 easier to use and understand than Babel 5. I suspect this is because I needed to configure Babel 5 anyway to meet my needs, so I was required to understand the configuration either way. Babel 6 made it much easier to understand what I was asking Babel to do; no magic, everything explicit.

With version 5, the default settings were a moving target (which I found confusing), and explicitly configuring it was more complex. Apparently the Babel team had great difficultly deciding what should be included by default as well.

Basically anybody that used Babel for something other than "6to5" had to jump through hoops to overwrite the defaults. Seeing as how the Babel team were trying to position it as a general purpose Javascript compiler, that was a problem for them.

So, maybe it's worse off for most people because of the change (because it doesn't work with zero configuration anymore), but plenty of people were better off because of it. The library became easier to maintain, and easier to use for a non-negligible number of users.

The major point of frustration was JSX preprocessing for React.

Need JSX? You have to use Babel. There is no zero configuration for Babel anymore, so you have to spend time learning it and resolving numerous build conflicts with cryptic error messages.

Todo list example with React+Redux+Babel6 takes 14 JS files, Babel configuration file, Webpack configuration file and Node package file to be written anew. This is what "Javascript fatigue" is about: when you get to the working first example from the documentation, you will be completely exhausted.

The amount of boilerplate with this "standard" setup is worse than with Java/Maven, and this is quite an accomplishment. :(

Reply on news.ycombinator.com