> And the React ecosystem tends to either lack typings or provide poor/broken typings.
React integrates really well with flow[1] (which is not surprising because they're both developed at Facebook) and in my experience flow's typesystem is more powerful (OCaml inspired) than TypeScript one (C# inspired):
- non-nullable types by default is a big deal (they added support for non-nullable types in TypeScript 2, but enabling it with `--strictNullChecks` is a breaking change, so I don't think many users have done the switch).
- the type checker is sometimes not strict enough to be sound [2].
No. The flow types around React are really poor. There are many things flow can't represent. The types are 'private' (all types in flow with a dollar in the name are private, not publicly supported. eg. React$Element).
The implementation of React$Element is hardwired into flow. If you have to include specific support for libraries it tells a lot about the expressiveness of the underlying type system, doesn't it?
There is no way to represent a react node, fragment etc. Properly typing children of a react component is impossible.
> It lacks access control for class properties/methods, I wouldn't call that powerful.
You mean `private` and such ? Well JavaScript don't support taht either yet, and flow is a type-system for JavaScript, it's not a new language on its own.
About the «powerful» word: Flow has had an algebraic data type (ADT) from the beginning, the kind of type system you'd find in functional programming languages, whereas TypeScript has and Object-Oriented type-system (à la Java or C#). ADT are usually considered «more powerful» since it offers more ways to write logical invariants in your code. The recent versions of TypeScript tries to retro-fit some features of ADTs into it, like non-nullable types or sum types, but it's a bit hacky IHMO[1].
React integrates really well with flow[1] (which is not surprising because they're both developed at Facebook) and in my experience flow's typesystem is more powerful (OCaml inspired) than TypeScript one (C# inspired):
- non-nullable types by default is a big deal (they added support for non-nullable types in TypeScript 2, but enabling it with `--strictNullChecks` is a breaking change, so I don't think many users have done the switch).
- the type checker is sometimes not strict enough to be sound [2].
[1] : https://flowtype.org
[2] : http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...