There isn’t a flaw with Flow or Typescript but it’s a very bolt on experience. If you use other libraries without flow types you’ll lose type safety across your app. Flow is good but Reason is like Flow on steroids.
The ML type system has a LOT more power than type systems like Java/Flow/Typescript. You can actually get the compiler to eliminate invalid states in your program at compile time. I posted a video here that goes into detail with a great example (think about how this would change your React State if you had some kind of a connection status view for example: Showcase where type is extremely useful in your program?)
They do have OCaml compiling to WebAssembly but I think the whole ecosystem is waiting on a built in garbage collector before anything can realistically be used. However, in React Native there’s a possibility to run native OCaml there instead of JS.
Some of the things that I didn’t realize going in:
Type inference - this is a huge help for me… you can get really far without writing any types annotations. You can lock down the interface later in an interface file or by manually adding the type annotations in the source code. Using Flow feels like your back in Java, having to type a lot more.
100% type safety - When I was writing Flow types I had a hard time getting 100% coverage across my code… this left holes in the program and promoted more laziness as I can’t get 100% coverage anyway.
Stable language - OCaml has been around for decades so the type system won’t need to be constantly changed (as opposed to a new flow type version coming out). Reason’s syntax may change as it’s newer, but a lot of those breaking changes have code mods.
. There’s also work going on to make it easier for JS apps to interact with Reason component by providing flow and typescript type definitions automatically. I would checkout this interview with the creator to learn why Facebook chose to back this project:
Hope this helps!