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).
218 karma · joined March 19, 2012
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-...
Regarding #1, I don't personally like JSX, but a lot of people do, so maybe they should use Flow. It seems likely the TypeScript compiler would barf on code that employs JSX.
Regarding #2, I can't see how that will drive any appreciable adoption of this tool. If you care enough to statically analyze your code, you probably care enough to annotate it to get the much stronger safety guarantees that will provide (not to mention other benefits, like "free" self-documentation, and enabling more sophisticated tooling, that have been discussed elsewhere at length).
Maybe I've missed an important use case here, but that's what I've been able to piece together since I skimmed the article. And since the author was recently interning on a large React codebase and never mentions TypeScript in the article, I have a feeling he falls into use case #1 above.
Well, in light of the fact that the author makes reference to his game industry background, you may find interesting the perspectives given in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...
And partial source code for the library described in the paper: https://github.com/paulhodge/EASTL