First, let's note the difference in philosophy: TypeScript aims for fast analysis because you can to compile it down to JS before you can run/test it. flowtype is meant to be an async analysis that can run continuously with changes since the last analysis, or in parallel with your eslint and bundler rules. As such, flowtype's type system and analysis is not quite as concerned with speed or memory usage in service of potentially finding more bugs.
On two occasions I have tried to roll out flow in React Native applications, and on those two occasions we ended up backing out after a few weeks. Some detail: flow doesn't have a public roadmap, and what version you use is dictated by the react/react-native dependency and the annotations in react-native itself. flowtype also has some hard-coded aspects to help the analysis for React, so major updates to React itself sometimes also require updating flowtype to match. React Native upgrades then get gated based on your dependent libraries (or flow-typed) being updated as well: flow-typed/flow-typed#1857 (comment)
This is a cheat only Facebook can do, the rest of us have to duplicate our definitions and there's currently no way for one definition to depend on another. The reason this works at all for anyone is because Facebook has a monorepo in their deployment of flow, so packaging and versioning aren't issues for them: flow-typed/flow-typed#2842
Following both TypeScript and flow over the last two years, and talking with core committers to both, they are very competitive in terms of core type system and analysis features. One finds bugs the other doesn't, and vice versa. Both have the downside of being single-vendor solutions, and neither are managed by independent standards bodies. Neither has full support for variadic generics, which was a key type system feature for C++ and C#. TypeScript appears to be pushing back on this feature due to the compute required (read: build times) in common cases, whereas flowtype is making more progress. These kinds of features are less important for app developers, but more important for library developers.
Microsoft has published a spec for TypeScript under the Open Web Foundation, and has a reasonable history of merging code changes and some spec changes from third parties (50% contributors are external in the last month). So far they have hit all of the release dates for milestones in their roadmap over the last year. Both of their issue trackers and PRs are a mess with many, many open items. That being said, TypeScript has had 346 commits over the last month versus 291 for flowtype. The diversity of committers is roughly the same between them.
Since babel 7 is supposed to enable generation flowtype from TypeScript definitions, I feel that TypeScript is the better and more flexible choice for developer experience and bug-finding. Developers can get near-instant feedback as they type in their IDE without draining battery life or using gigabytes of RAM, and we can do flowtype checks (and minor manual) annotations as-needed to cover the gaps in TypeScript analysis. There are currently blockers with TypeScript, (like babel/babel#8244 (comment) ) but I feel we have a better chance of contributing/funding the changes we need in babel and TypeScript versus flowtype and flow-typed.
I've only really come around to TypeScript being the practical option in the last few months after deep discussion with my colleagues and the community. I hope laying out my reconciliation process helps others, whatever the decision people make are.
Great analysis. TypeScript + Flow is such a cool concept. I'd love to read more about the known gaps you're filling and if you find a good way to get everyone to play nicely. Please write more, this was great!