Hacker News new | ask | show | jobs
by thejameskyle 3489 days ago
The change in Babel 6 was this:

   $ npm install babel-cli
   $ babel src -d lib
To this:

   $ npm install babel-cli babel-preset-es2015
   $ echo '{ presets: ["es2015"] }' >> .babelrc
   $ babel src -d lib
It really wasn't that big of a change.

Also, we did give it a new name. It used to be 6to5, and we changed the name around the intention to make it more generic. Which Babel 6 was the culmination of.

As for communicating with the community. Yeah, we can't address everyone at once or even reach them all. We could shove it in their face (and we do) and still a significant portion would still ignore us (and they do). There's not much we can do about that. But they shouldn't come to us and say that we never said anything about this, because yes we did.

Also, the article I referenced about Angular 2 was not talking about the transition from Angular 1 to 2. It was talking about ng2 as its own thing, criticizing it's design more than anything (just in a really shitty way).

6 comments

James, I reached out to Sebastian, on multiple occasions in January to apologize. Phabricator via the chat feature, Twitter(blocked), email, etc. I can't even remember all the mediums. So if you can pass it a long that would be cool. Sure, Sad state got a little personal, but I'm not too stubborn to admit when I'm wrong. I'm sorry it affected the team so much, obviously not my intention. Just tried to use hyperbole to bust the Javascript echo chamber.

I used Babel since the beginning when it was 6to5, and seeing the Babel 6 change was rough to say the least, and I made it personal when I shouldn't have. It's just software in the end.

Not invested in this discussion, but it sure is refreshing to see someone change their mind in "real time" and show self awareness. I appreciate that!
It's what the world needs right now.
Yeah, I don't think a name change would have fixed this case. Here you were just wrong. You failed to predict the impact of such a visible change and as such did not implement the change in such a way to minimize impact or use an appropriate migration plan so as to not surprise users.

Sadly the users most likely to be inconvenienced by a change like that are also those with the least knowledge of the product(like if you don't know what babel actually does, you aren't going to understand why the cli stopped working or why you need this new config file to make it do something). That leaves them frustrated and angry but with a poor understanding of why and what adequate solutions would be. There is nothing you can do about that, asking the community to be nice isn't going to help because most of your users don't think they are even in a community.

The only things you can do are try to anticipate them a bit, and to try and count the criticisms but ignore their contents(and search yourself for the deeper cause). Luckily the first part is sort of easy for JS projects because most of the active tooling development in JS is on things that have been done many times before. In this case you could have just looked to gcc and wondered for a bit why they still ship with --std=gnu90 by default, despite how maddening that must be for all the developers working on new features that go underused as a result. You could have looked at all of the other software that is stuck dragging forward dumb configuration systems with complicated defaults and layers of precedence instead of just asking users to fill in a few config fields on first run.

So I do want to say that I am so sorry on behalf of your users, and I really appreciate the work that you do. However that was a real mistake with babel and a big part of improving the interaction between you and your users unfortunately falls on you.

This is what makes open source (and a lot of volunteering) really difficult. If you look at a sibling post, one reason given was, "Just tried to use hyperbole to bust the Javascript echo chamber." I think that's true for many of the egregious examples, but it still hurts and isn't fair the people working on the project.

The lines get blurry, XP has a business case for dropping support, Google (and GNU) are decently funded I imagine. I'm not sure how much his work at Facebook and his contribution to open source overlap, but it's not fair to be outraged or make demands if you're not paying anything--especially if this is all work done own his own, for fun.

Hell, I work in an industry where we pay for expensive software but don't have a venue to complain about bugs or feature changes because they don't make themselves accessible. We could pay 10x more money and get a support contract where we can yell at them, I've worked at places that do, and they likely won't address your issues. Pay 100x more and they'll write a custom version for you. With OSS, many times, we get this for free.

the cli only stopped working the same on new projects with v6, old projects should have continued to work... though a post-install that created a default .babelrc would have been nice.
I think the main issue with the transition of Babel 5 -> Babel 6 was a cognitive one. A few CLI one-liners don't really address this. Babel was zero-config and now it's not. I now need to understand what presets and plugins do and how to order them to get desired results when transpiling.

Ultimately, it was inevitable and I think it was a very good thing! I'm really happy that Babel 6 exists. But figuring out your Babel presets and plugins is undoubtedly another thing that we have to think about when we start a project. Similarly with JSLint/JSHint -> ESlint.

Thank you for your great work, I use Babel daily and Flow sometimes (less often than I should).

Anything more than the two presets "es2015" and "react" (we never should have shipped "react" on by default, we just didn't have a pluggable parser before) required configuration in Babel 5. A regular complaint that we had was that the Babel <5 configuration was really annoying because it involved three separate whitelists/blacklists
> But figuring out your Babel presets and plugins is undoubtedly another thing that we have to think about when we start a project. Similarly with JSLint/JSHint -> ESlint.

There's ways around this. Tools people built to make this easier.

I created a preset of my own for Babel, and now I use that for any new project, no figuring it out every time. I know what my preset has in it, and if I need anything new, I can put it in and all other projects have it now too.

Same with ESLint, there's tools such as Standard (And the standard-engine if you don't want to use actually standard) where it IS drop in again.

First off, I am sorry that it looks like my comments have continued to inflict pain on you and that really wasn't my intention. I agree with your main point: we should be decent to each other, and I apologize if I wasn't.

Second, I think you got burned harder on Babel because it was part of a bunch of starter packs. A lot of non-front-end guys like me started with things like Yeoman and didn't understand what was in the template, just that it worked for a while and then it didn't work.

Unfortunately, these seem like things you couldn't necessarily prevent by reaching out more, which is part of what I was trying to convey. The other party wasn't listening. And that's on us.

Anyway, I hope that people are more decent to you and you recover. We really do appreciate the work you are doing.

What specifically do you find 'really shitty' about that Angular 2 article? The reddit thread gets pretty unpleasant but the write-up itself is strident but generally sticks to specific issues. It doesn't seem like 'an attack on the maintainers', certainly not by title alone.
Because (if I'm remembering the article correctly, am working from volatile memory and not gone back over it, so apologies if I've overcooked this) it's not phrased as particularly constructive criticism, it basically just hilights general pain points in a slightly snarky way.

Learning to take criticism well is HARD, I'm still relatively shit at it despite my best efforts, but learning to give criticism well is even harder.

As a community, we lack some degree of common community spirit, to coin a particularly trite phrase.

The syntax of your first example is so, so much easier to grok than the syntax of the second.
You don't have to literally pipe it into a file, you can just open it in an editor. The "syntax" in the example is just an example.
wait, really?