Like skybrian's reply mentioned, I don't think this is actually an area where Flow is much stronger than TypeScript, if at all. AFAIK, virtually all vanilla JavaScript should also readily compile as TypeScript.
In my mind the difference is that TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. Meanwhile, Facebook claims that "Flow understands the control flow through the program."[0] That's great in theory, and maybe their control flow analysis is really quite sophisticated, but ultimately isn't this isomorphic to the halting problem?
> ...TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations.
TypeScript infers the types of local variables. For example, the following unannotated code would cause the TypeScript type checker to fail:
// error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.
[1, 2, 3].join(4);
However, even when the TypeScript typechecker fails, TypeScript still produces JavaScript output. As a result, you can use TypeScript to incrementally type your program, and simply choose to ignore type checking errors. TypeScript only fails to produce output if there's a syntax error, or if you are using TypeScript import statements without specifying a module type.
Well, it's kind of uncanny how precisely that article addresses my misconceptions at the outset. Thanks for an awesome link (and the related k-CFA article at the bottom).
In my mind the difference is that TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. Meanwhile, Facebook claims that "Flow understands the control flow through the program."[0] That's great in theory, and maybe their control flow analysis is really quite sophisticated, but ultimately isn't this isomorphic to the halting problem?
[0]: https://code.facebook.com/posts/1505962329687926/flow-a-new-...