Something I didn't mention in the post that might deserve calling out specifically is that Rust maintainers actively decide to work in crates instead of in std for many things.

This means that you have the language designers themselves maintaining some of the most important crates in the ecosystem, and baking it into their process to iterate on the language itself. The result is really high quality crates and the community is better for it.

I'm not trying to dunk on JavaScript/npm packages though, or anyone involved in developing the language. Clearly the JS community has found success and is meeting a lot of people's needs. We can accept that Rome's requirements are different than most people using JavaScript.

Hi Jamie! I thought the article was pretty thoughtful and I'm sorry it's gotten such a mixed response in the comments here.

It was interesting seeing your commentary on Red-Green trees and how they're used. I'm excited at the prospect of a rust-analyzer level of type-checking and correction for TS/JS. As a technical security person, I also see a lot of potential for such tooling to do things like data-flow analysis, which is pretty much the gold standard for detecting things like untrusted input or dangerous interpolation.

Are there plans to support that kind of security tooling in Rome? If not, is there any interest in supporting something like that in it's eventual feature-set?

The difference here is accessibility.

There's a number of public ways (which could be automated) to find out information like people's home addresses, but generally it's pretty difficult to figure out how (provided someone isn't just publicly posting their address).

Online harassers are often deterred simply because it takes too much effort to find out the information to do more harm.

Doxxing takes some amount of know how, and that's the only thing preventing it from happening more often.

> Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); }

That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.

Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc.

With Flow you don't even have to opt-in to a new syntax. You can just use comments:

    function foo(val /* : boolean */) /* : string */ {}

Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all](https://medium.com/@thejameskyle/flow-mapping-an-object-373d...).

> With Flow you don't even have to opt-in to a new syntax. You can just use comments:

So you use a opt-in comment-based syntax instead of a opt-in non-comment based one for type-annotations.

Hardly a big difference.

> Using really powerful inference you can also write much fewer types

I'm just going to assume you didn't know typescript does this too.

Typescript is nice. You should give it a try once. You may end up surprised:)

Comments don't change it from being valid javascript whatsoever.

> By taking advantage of Babel, ESLint, Atom, etc.

Doesn't TypeScript actually predate all of those tools? So that logic doesn't seem reasonable.

Those all exist in Flow as well.

I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.

Nowadays, typescript inference is not any worse than Flow's though.

If that's too much you can also do:

    function bar(x) /* : string */ {

No compiling necessary

Comments is definitely the easiest way to get doing. But also if you're already using Babel and ESLint, you can add Flow in very few steps:

1. Setting up with Babel: (note that if you are already using the "react" preset you don't have to do anything)

    $ npm install --save-dev babel-plugin-transform-flow-strip-types

Then update your `.babelrc`:

    { plugins: ["transform-flow-strip-types"] }

2. Setting up with ESLint

    $ npm install --save-dev eslint-plugin-flowtype-errors

Then update your `.eslintrc`:

    { plugins: ["flowtype-errors"] }

Then just install `flow-bin` and create an empty `.flowconfig` file in the root of your repo and you're done. Now you have Babel compiling your code the same as always and you can use the Flow type syntax, and with ESLint you probably already have your editor all setup to show you warnings.

We're trying to integrate more with tools like this so you don't have to go changing your entire workflow. It shouldn't be so hard to add types to your existing JavaScript code.

For eslint I'm using plugin "flowtype", and under "extends" I have "plugin:flowtype/recommended". Do you happen to know what's different compared to the eslint-flow package you mention? I took the first one I could find, didn't want to spend hours with the eslint part of using Flow since I was busy with all the errors reported by Flow during the conversion process.

EDIT:

Ah I think I get it, it's for editors that don't interface with Flow but only with eslint. Well, since WebStorm has Flow support - even though it's new and there are a few tickets open - I guess I should stick with the plugin that I already chose.

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.

Hi James,

I'm really sorry to hear about the difficult time you've been having. I can see how that would make an already thankless job like maintaining an open source project even more frustrating.

During my time as a Lerna contributor I was careful NOT to abuse my power. The few times I merged PRs I checked with Henry first. I pinged you at the beginning, too, but stopped eventually when I didn't hear from you. Mostly what I did, though, was triage issues and work with other contributors to get PRs into shape. I spent a lot of time over the summer working on Lerna, and only a small part of that was the code I wrote myself.

Then, suddenly, you started deleting my comments and locking my issues. You removed me from the organization without any discussion. That seemed to me an abuse of YOUR power. It hurt.

Please re-read the first comment of mine that you deleted. It wasn't meant to be aggressive. It was a plea.

---

My inspiration here comes primarily from two sources:

1. Using Lerna every day and thinking about how it could be improved to make my life easier.

2. Listening to feedback from _other_ Lerna users about how it could be improved to make _their_ lives easier.

You're one of the original core team, and I don't want to alienate you. Your rewrite of Lerna put in place a foundation that has been a pleasure to work with. But lately maintenance and improvement has continued in your absence thanks to contributions from Lerna's fledgling user community. Do you plan to reassume this responsibility?

---

That was here [1], but you deleted it and then locked the issue. I hope as you read it now you can see why it was surprising and hurtful that this was your response.

[1] https://github.com/lerna/lerna/issues/334

James,

Thanks for the reply, and the apology. Your situation really sucks, and I hope it gets better with time.

Please consider taking a break from some of your projects.

People keep assuming I have something against sharing criticism or frustration. I never said that. I explicitly said that's not what I'm trying to say.

I'm saying that when someone does it in a way that is in pure unadulterated anger that the community should not reward them for it. It's unhealthy for everyone.

If I can ask, what's your alternative to breaking changes?

Most of the time when I see a large library make breaking changes, it's to solve a problem which can't realistically be "fixed" without breaking changes.

And even if they can provide a "shim" to allow people to use the old way of doing things, people see that the same as they see maintaining an old release. That you need to upgrade to the latest version or you'll be left behind.

I'm not trying to put words in your mouth, but it seems like the only options left are to "never improve" or "get it right the first time". And obviously the latter isn't possible pretty much at all.

I'd argue that most breaking changes are not about fixing problems. They are about API consistency and taste, like Babel 6 mentioned above.

If problem is a bug that people might rely upon, I don't mind fixing it. If problem is fundamental design-wise, however, the right way is to create a new library.

There are a lot of designs that never break anything (or at least try hard not to): Linux, macOS, Erlang, Java, Clojure, x86 instruction set, life on earth, and they all improve over time. And they obviously didn't get everything right the first time.

I dig Babel 6. I'm glad they took the major bump, which allows breaking changes, to improve things.

The major bump means it's opt-in, so folks can continue to use the older version without breaking their workflow.

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

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.