Dear JavaScript

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.

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.

You don't want to compile everything every time.

We target a platform that has arrow functions, we don't need to compile them in any more. Not a big deal for arrow functions, but a HUGE deal for async/await, or for-of statements (both of which will compile to a LOT of code which includes a pretty large amount of runtime-checking to work).

But there's also the fact that you do pack some of it into the final build. Many transformations include a lot of boilerplate, "helper" code, and in some cases big polyfills. Getting rid of those when possible is a huge bonus. And Babel 6 paved the way to allow you to incrementally remove those plugins one at a time as your target platform supported the feature natively (and at a speed that you are comfortable with). We currently only transpile async/await in one of our codebases, once that lands in node.js and is stable, babel will no longer be part of our pipeline. That's not something that we could have done easily with the Babel-5 system.

But it also takes babel from a "ES6 -> ES5" tool and makes it a general compiler. Babel now has plugins that will minify the code, plugins that will drop dead code, plugins that can perform "GCC style" optimizations in terms of IIFE removal, constant inlining, loop-unrolling, and more. Before the Babel-6 change, all of that would either need to package it's own AST parsing, or it's own bastardized version of babel. Now it's as easy to write plugins that do things like remove the prop-type code from a React project [0], or eliminate unnecessary closures [1].

There's also the ability to save space and install time on the developer machine. Not that big of a deal to me, but I hear others complain about it from time to time.

But those are just the reasons why I like that it's modular.

[0]https://github.com/oliviertassinari/babel-plugin-transform-r...

[1]https://github.com/codemix/babel-plugin-closure-elimination

I got to work on Lerna for about two months while working at Cloudflare in order to ship cf-ui. Otherwise it was in the middle of a period where I mostly backed out of doing open source because of frustration with the community from early this year. So if Cloudflare hadn't done that I probably never would have gotten involved.

I'm sorry I was often short-breathed when responding. I'm sorry I shut people down more than a few times. From my perspective Lerna was feature complete until Yarn was launched, and people were only ever making feature requests so I didn't see a big deal.

At one point I was frustrated and Bo made it seem like he was going to abuse his power as a contributor and I got freaked out and removed him. He only got more and more vocal from there and I just pushed him out entirely.

Since then I've started a new job, a new relationship, I've been exhausting myself writing new talks. I've had family problems, work problems, fucking country problems... a family member who has been having suicidal thoughts, family who have practically disowned me for being gay and refusing to take their shit.

To be honest, I've barely been getting by in life before we even start talking about open source. I have to take care of that first.

I'm sorry.

> Now I see you meant to drive the undesirables out of entire Javascript language completely and force them into another language

Not at all. I misinterpreted what you meant in your concern over them forming other communities.