Comment by fusiongyro | Hacker News Reader

Comment by fusiongyro | Hacker News Reader

I don't want to distract from the main thrust of the article, which was that we should be decent to each other even with our criticism, but I think both his examples (Babel 6 and Angular 2) had something in common that lead to a lot more anxiety: they changed the essence of the software in a way that a major version bump is not enough to communicate.

I'm speaking especially of Angular 2 here. It's essentially a completely different framework. You don't expect going from Postgres 8 to Postgres 9 that the underlying query language is going to be switched out for a different one. Regularly communicating with your users, as Angular and Babel did, only reaches the engaged part of the community. A lot of workaday programmers are not that deeply engaged. You're just moving their cheese, and it makes them mad.

A better approach is to spin off a new system and give it a new name. This is what happened with Express and Koa, and it gives you a way to gauge whether people actually want the change you're making or not. I predict Angular 1 is going to be the Windows XP of front end development: lingering on for much longer than anyone expects. Slow and principled change is not a common thing in Javascript-land but it is what legions of software engineers expect. A lot of front-end development, like it or not, is being done by full-stack engineers or other engineers who are not front-end developers exclusively. Asking your echo chamber if they like your ideas is not really a sufficient sounding process, especially if you're making a deep cut.

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

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

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

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

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.

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?

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.

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 went to the Angular 2 docs and was thinking "this is nothing like Angular 1, looks like a completely different framework." Then I read from them "this is nothing like Angular 1, this is a completely different framework."

Should they have gone with a different name? Probably. But my guess is that they kept it for 2 reasons. The first is the name recognition. The second, more important one, is that they're letting us know that development on Angular 1 is winding down and this is the place where their new resources are moving to.

That and they also have an officially supported migration path from Angular 1 called ngUpgrade which allows Angular 1 & 2 components to communicate with each other so you don't have to do a big bang rewrite.

imho they should have bumped to 3 at release to avoid old articles referencing outdated apis as ng2 had a lot of breaking changes along the way..

A better approach is to spin off a new system and give it a new name

Great point. I think some developers or teams feel compelled to update the latest even if they are happy with what they have because using an older version number gives the appearance of being behind the standards and practices. In a case where changes take place to the extent that it makes the previous framework difficult to recognize or breaks compatibility in a big way, this pressure would ease if the new version just had a completely different product name, as in a way that's what it is anyway.

Rich Hickey just did a great talk about this sort of thing at Clojure Conj: https://www.youtube.com/watch?v=oyLBGkS5ICk

I agree mainly for googleability. It's really annoying searching for Angular 1 stuff and getting Angular 2 results and vice-versa.

Remember this behaviour is encouraged by the deprecation warning notices of npm. I want my project to compile cleanly, but without me changing anything, from one day to the next, I may face a bunch of warnings because some maintainer somewhere decided they have a fresher version (lodash, pug/jade, node-uuid etc I'm looking at you).

Change your npm log info to just errors. Warnings don't mean your build broke, just that the version of a dep you installed is no longer supported and if you want bug fixes to upgrade.

:clap:

So then you're gonna have people looking at you and saying "ugh, Angular is old and outdated, you should be using ng-not-angular-but-newer-and-shiner!" and everyones gonna be upset that they didn't find out what the new versions name is so that they can upgrade to that.

If people have a hard time googling that info OR angular devs can't communicate that info well, then problem lies elsewhere.

Besides, the one reason, of using a different name is, to convey that it is a different framework just like others.

It's because being on older versions limits your upgrade options. The further you get behind the more painful upgrading becomes.

You don't want to be in a position were you can't fix a bug because it's in the framework and you're several version behind.

There are also security issues with using older versions.

I said the same thing when they first previewed Angular2: call it something else. everyone would still know it comes from the Angular team and it wouldn't have pissed so many people off.

I disagree that Angular 2 is a completely different framework. Rather, it's like Angular 1 re-imagined for the ES6+ world. Many of the concepts are the same, like data binding, "scope," and Dependency Injection. The big change is moving to new syntax and a new foundation on object-oriented concepts. The framework had to adapt and shed some of its custom solutions to what are now available standard in the language.

Reply on news.ycombinator.com