General Feedback

Hi Flow Team!

I was reading [this twitter thread today](https://twitter.com/twexler/status/888819426371354624) and it prompted me to leave some feedback on my experience with Flow. We've used both Flow & TypeScript in our team, though we started dropping Flow out of our builds about a year ago. Here are some pain points that we experienced with Flow and a comparison with our experience using Typescript:

## Shared Types
Shared type definitions are better documented/easier to get started with in Typescript, specifically in the realm of sharing declarations across npm packages. Having type definitions a quick `npm i` away was vital for rapid adoption. It immediately provided benefits to untyped projects and helped encourage devs to start exploring the type system.

I don't think that Typescript has really "figured out" types as dependencies either. There is currently no easy way that I know of to semantically version a project that tracks another semantically versioned project so `@types` just tends to bump the patch number. This introduces breaking changes all the time. Also, multiple versions of the same declaration dependency will cause conflicts. This is a constant thorn in our side which also prevents us from "locking down" to specific `@types` versions, ensuring that the breaking changes issue I mentioned above is unavoidable.

## `/* @flow */` vs. `.ts`
I think using `/* @flow */` rather than a custom extension causes usability issues. It's not as self explanatory to new developers that they are "working with a different language". When one of our new developers runs into a `.ts` file, they generally are able to google it, find Typescript Documentation, and at the very least familiarize themselves with the language before asking the more senior devs about it. With flow, a lot of times a dev would never know they were working with flow annotations. It wasn't clear when they were working with a "flow project" and when they weren't (it doesn't help that `.flowconfig` is a hidden file). This was made even more confusing by some community tools like WebStorm not requiring `/* @flow */` before using flow annotations. I think I much prefer the clarity and strictness of the extension based language.

## Editor Support
As far as I could tell, editor support was mostly absent for Flow unless you forced all your developers to use Nuclide. The Nuclide project seemed focused on internal use and consequently came bloated by default. It had it's own plugin manager and came with a slew of plugins that we will never need and heavily modified the atom interface to include features for languages we will never use. Considering that all I wanted was type hints this quickly turned me away from the project. I'm not sure if I ever actually got the type checks working with Nuclide.

We use WebStorm where I work and the Typescript integration was pretty solid. Most of everything you would expect "just works". There are a few cases where WebStorm will produce weird errors that `tsc` won't emit that can be a little annoying. Visual Studio Code is a pretty nice lightweight editor and I've been using it pretty regularly now. Having "per file" type checking by default without any extra setup is really nice. There is a bit of extra work for getting those type checks working project-wide, but it's not too bad. With both editors I've noticed that sometimes the type checks "get stuck" and you'll have to manually rerun type checks or restart the editor.

## Build Integration
For us build integration with Flow was a pain. Community tooling was lacking. Webpack integration was almost hostile. This generally meant that we would have to run flow checks in a separate process from our normal watch task. This made it difficult to enforce those type checks and reduced their discoverability. Eventually I accidentally dropped flow checks from our deploy script during a rewrite and no one even noticed.

I think one of the pieces that a lot of people ignore when comparing the two languages is that Typescript is not just a language, but a build system as well. In my opinion (as the guy who worked on our site's build system) the number one differentiating factor was that working Typescript into our builds was not just easy, but was a joy. Here is a list of build steps that we got for free by dropping in a `tsconfig.json`:

- ESNext compilation
- JSX compilation
- Bundler (for libs anyway)
- Watcher
- Minifier

In most cases this was enough to drop our entire build for a project. This is **huge** considering how much development time and maintenance goes into the average JavaScript build system these days. In this sense, Typescript is not just solving JavaScript's lack of a type system, but is reducing the complexity of the JavaScript dev environment in general. For frontend projects we still needed to keep Webpack around, but community tools like `awesome-typescript-loader` made Webpack integration a breeze.

## On the Subject of Soundness
In [this tweet](https://twitter.com/calebmer/status/889137083301810176) Caleb mentioned that Flow can guarantee type soundness, while TypeScript can't. I agree that this is great, but it's not as strong of a selling point at the moment as one might think. The reality of JS is that most projects have no type checking at all. For a large untyped project, adding _any_ form of type checking is going to drastically reduce the number of errors going out into production. If your product is regularly breaking in production _today_ a low barrier to entry is much more valuable than complete type soundness. If I can't figure out how to use the tool, I'm never going to be able to reap its benefits.

This wasn't meant to pick on Caleb as it seems [he agrees with the usability issues](https://twitter.com/calebmer/status/888896969560563712), it's just meant as a note on marketing.

## Closing Remarks
I did enjoy Flow when it was working smoothly. It sounds like y'all are aware of several of these issues, but I hope that by sharing my experience it helps highlight some of the larger pain points. Some of the above issues may already be solved. It could also just be that some of these issues were not well documented. I'm not sure. Either way, best of luck as y'all continue your work to improve Flow and its community.