The Flow team at Meta writes about Flow, the JavaScript static type checker, covering language features, performance, and project direction.
HN links it when comparing Flow with TypeScript, such as enums and opaque types, and for its statement that internal Meta needs come first.
> [citation needed]
I don't have anything but own anecdotial evidence to provide. Would be cool if there were some good, recent benchmarks between the two, but I wasn't able to find any.
Maybe I've just configured something wrong, but I keep facing this issue where autocomplete stops to think suggestions and might just freeze the whole VSCode for a second. This is in a small project that has some fairly large library definition files (namely, aws-sdk).
If you search for "TypeScript performance", you'll find a bunch of issues and posts discussing the subject, so I don't think I'm totally alone in calling it out.
Granted, Flow gets it's share of similar search results and I have also experienced similar issues where a recheck sometimes takes long and CPU usage jumps very high. This side of Flow has been consistently improving between almost every release, though. Most recently, a couple months back, their switch to this new "types-first" architecture [1] is supposedly unlocking something like 50%-90% perf improvements compared to what they vere before.
My point with this isn't to question your experience with Flow, I've sometimes faced similar issues. I'm just saying that, depending on the Flow version you were using, things may have changed a lot for the better.
Just so that I'm not talking _completely_ out of my ass here, as a quick very unscientific test I cloned the Tutanota project's repo [2]. SCC says there's 967 JS files, consisting of 205433 lines of code in…
Flow feels almost like the Betamax to Typescript's VHS - Flow is better technically in many ways (in addition to the things you mention, I miss being able to spread the properties of one type into another, rather than having to inherit from an interface), but in practice, in terms of engineering cost, it's so much more expensive that it's hard to justify using it.
Flow's team have made it clear [0] that they don't care about usage outside internal Facebook projects, so since Facebook (from what I hear) uses few external JS dependencies, support for library types is terrible - there's no practical way for library developers to ship Flow types with their library. The third-party flow-typed repository helps somewhat, but relatively few libraries are covered there, so in practice you'll need to write your own typedefs for most libraries you want covered.
When I worked in a Flow codebase, I enjoyed writing Flow types for things, but it was only ever fun in a sudoku-puzzle-solving, Zachtronics-game kind of way. The tools provided were technically enough to express whatever you wanted, but it always took some lateral thinking. TS certainly allows for the same kind of type astronautery, but as a non-library app developer you never have to resort to that; you can always fall back to something slightly less strict that covers you from most real-world problems without the all-or-nothing strictness Flow mandates. In the end I was the last holdout on the team advocating for not…
Great list!
Related to your point on supporting 0-transpilation workflows as a first class citizen, is the fact that Flow was explicitly just type annotations & checking, and aimed to introduce 0 runtime constructs.
This is something Flow did from the beginning and TypeScript eventually established as a non-goal after already implementing several runtime constructs that they can no longer afford to remove for backwards compat [1].
Though interestingly enough, Flow themselves recently announced they're going to start introducing runtime constructs, which is an interesting plot twist [2].
[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals
[2] https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b
Ah I see. That can be achieved since Flow 0.51 with opaque types[1][2]. It seems like TypeScript hasn't yet caught up with this functionality[3].
[1] https://medium.com/flow-type/hiding-implementation-details-with-flows-new-opaque-type-aliases-feature-40e188c2a3f9
[2] https://flow.org/en/docs/types/opaque-types/
[3] https://github.com/Microsoft/TypeScript/issues/15807#issuecomment-301196459
I read https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b here like two or thee weeks ago. In short, their priority is still internal teams and projects.
Another example would be the difference between their enum features: https://medium.com/flow-type/typescript-enums-vs-flow-enums-83da2ca4a9b4 "TypeScript Enums vs. Flow Enums"