I'd argue that porting from JS to TS is a very different beast than porting from Flow to TS.

I've ported code from JS to Flow and could say the benefits are similar to those of porting from JS to TS.

The most relevant part in this article IMHO is the conclusion:

> things like a strong community and availability of type definitions are more important because weak type inference can be solved by "handholding" the type checker a bit more.

I think it's important to highlight that this may be true of his project but not necessarily yours or mine.

Flow's type inference provides a much deeper level of confidence than TS with far less effort, for example, typing only the public interface of a module is often enough to surface type mismatch errors several functions deep within the module. In TS, you'd have to type every function signature to get the same level of confidence.

What worries me about flow is reflected in the comment from the facebook engineer linked from the article: it seems the flow team is focusing heavily on facebook-scale performance at the expense of most every other aspect of the project. A while back, the existential operator was quietly deprecated in the name of perf, and lately some updates have been of questionable soundness, e.g.

https://flow.org/try/#0GYVwdgxgLglg9mABAdxFAFAQwFyIPIBGAVgKb... (compared to http://www.typescriptlang.org/play/#src=function%20wut(a%3A%... )