That's a very good reason. I wish there were more community-provided types for flow. I think Immutable.js has only just fixed the last issues, but that's really been bugging me for the last few months. ("no default export" and "isEquals".)
* Flow requires Babel.
Not a huge deal for me, since React Native already requires Babel, and I personally like working with Babel. I use a number of Babel plugins, such as "transform-decorators-legacy" and "module-resolver".
* Flow is written in OCaml. It could probably make it more difficult to install than TypeScript.
Not at all, installation was very quick and easy. You can use either npm or Homebrew.
One technical limitation that complicate contributions to the flow-typed repository is that there is no way of writing typings that depend on other libraries' types [1]. For instance, flow-typed has a library definition for `rxjs`, but it is not possible to e.g. add a definition for `redux-observable` that reuses the RxJS `Observable<T>` type, because there is no way to express that the typings of `redux-observable` neeed the ones of `rxjs` to function. So typings for such closely related libraries tend to not exist in flow-typed.
To work around this problem, some libraries like styled-components require you to manually include the library definition files it requires in your `.flowconfig` [2], but this is a rather hacky workaround.
[1]: https://github.com/flowtype/flow-typed/issues/16
[2]: https://github.com/styled-components/styled-components/blob/...
So are you saying that there are no flow types for redux-observable? I guess that's not a deal-breaker, since flow-typed will just generate stubs. Also, it looks like react-observable is a super high level abstraction, so I'm not even going to be writing that much code.
[1] https://www.youtube.com/watch?v=AslncyG8whg&feature=youtu.be
Could you elaborate on that please? Is it impossible to skip Babel when using React Native?
> Not at all. Installation is very fast and easy.
(Last time I checked Flow npm package gives you binaries.)
I'm sure Flow installs fine in "standard" environments, like an OSX laptop. I was thinking about more weird places, like CI servers where you can't fully control the environment. I was burned enough about stuff like that in the past.
Yes, the React Native packager depends on Babel, and uses a react-native preset. When you start a new project, you get this default .babelrc:
{
"presets": [
"react-native-stage-0"
]
}
Here's the only issue I found, which is now closed: https://github.com/flowtype/flow-typed/issues/247
> TypeScript has larger community.
It kind of depends. In some circles Flow is bigger. Mind that it is heavily entrenched in everything Facebook does, so it's treated as a built-in, first-class citizen in many circles (e.g. React Native).
> Flow requires Babel. TypeScript doesn't.
I'm not sure I agree. Objectively, depending on the kind of Flow you write, you don't really require any transpilation step.
Plus, subjectively, using Babel with TypeScript should not be frowned upon - there's a lot of advantages that Babel can provide that are outside of the scope of what TypeScript tries to do. Personally I use it to provide shims (via babel-preset-env) so I can target older browsers based on version configurations.
* TypeScript has larger community.
* Flow requires Babel. TypeScript doesn't. One less dependency to worry about. And in my experience TypeScript compiler produces better JavaScript than Babel.
* Flow is written in OCaml. It could probably make it more difficult to install than TypeScript.
P.S. React works fine with TypeScript. I haven't played with React Native though.