Just to add my experience here, I evaluated Flow and Typescript recently for a new project and found that while Typescript was more effort to get going with than Flow (things like needing .d.ts files for third party libraries which may not always exist on DefinitelyTyped, setting up the Typescript compiler config, etc.), the advantages of using it made it worthwhile.

Documentation and community support online for Flow seems quite light compared to Typescript - I get the sense it is mainly just used inside Facebook at the moment, and it was hard to find help for problems I encountered - and even with Nuclide, the IDE support for flow doesn't touch Typescript's (I guess partially because Typescript has definitions for the 3rd party libraries you use, which is usually quite a big part of JS programming) - the plugins for Sublime and Atom for Typescript are really impressive, as is Visual Studio Code - it's hard to imagine going back!

Typescript also seems to offer a more complete "correctness" check of your code, I guess because it is compiling it - I found that Flow didn't pick up on typos in things like imports, which led to runtime errors, whereas Typescript does. I also couldn't get Flow to validate my React prop types - I was probably doing something stupid here, but the lack of docs made it hard to know what.

The final straw for me with Flow was that at a certain point in the project, my Atom/Nuclide started using all my CPU with loads of flow-server processes, and again, I couldn't find a solution online, which made it useless to me.

Flow's lightweight nature is still appealing and I will keep an eye on it, but at the minute, for a commercial project especially, I think Typescript is a better and more mature bet. Shame it doesn't support non-nullable types though!

The main cost of using Typescript is the need to have definitions for third party libraries (although it is possible to create very basic "skeleton" definitions, just listing exported members as being of type "any", which doesn't give you type safety but is a quick way to get it to compile), and also interop with some "cutting edge" features like requiring CSS modules in a React component requires some hacks, but I think the benefit of having the code compile is worth it - I've found most of the time when a runtime error slips through, it's because I've used the "any" type, either in my code or for a library. I plan to write up my experiences at some point, as there's not a huge amount out there about using TS with the latest shiny stuff like CSS modules.

Also one other note on Nuclide - I had terrible problems with the version distributed through the Atom package manager - it would completely freeze my Atom and use 100% CPU and the only fix was to delete ~/.atom and start from scratch. Installing it from source fixed this, and even though I am now using Typescript, I am still using most of the Nuclide packages as it adds a few nice features (especially the inline lint/compile errors, not sure which plugin adds these but they appear on mouse over whereas the default Atom ones don't seem to). It does add ~10s to Atom start time, but otherwise doesn't seem to impact performance too much.