[lhorie]

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%... )

[brett40324]

> In TS, you'd have to type every function signature to get the same level of confidence.

I don't disagree, but isn't this the point? That by typing every function you can reliably have confidence in parameter types and return value types, and if your program is able to throw a type error on build, then it should and alert the developer that they're not logically correct in their implementation.

[lhorie]

My point is mostly that you can get away with explicitly typing less things in flow and still get similar levels of coverage. For example, consider this example:

    export function formatTime(time: Date) {
      return digitize(time.getHours()) + ':' + digitize(time.getMinutes());
    }
    function digitize(n) {
      return ('0' + n.toStirng()).substring(-2);
    }

Just a single type declaration is enough to let Flow catch the typo here. In TS, you'd also have to write the argument types for `digitize`. Importantly, if you wanted to explicitly add arg types for `digitize` w/ Flow, your editor can tell you what they are supposed to be.

[z3t4]

FLow seem to be better at inferring types. example:

    function foo(n) {
          return n*2;
    }
    
    foo("bar");

[z3t4]

Object seem to be any object (any type) in both Flow and TypeScript, if you change it to string, both Flow and TypeScript will give an error.