Flow vs TypeScript in React — My two cents
The pros and cons of TypeScript and Flow
Update. When writing this story, the support of TypeScript in Babel was not yet released. This has tremendously improved the integration of TypeScript in React projects. And Expo, a key element in the React Native ecosystem, has recently announced to move away from Flow to TypeScript (read announcement here).
Should you use Flow or TypeScript in your next React project? I recently had a bit of a dilemma with this question, and I would like to share my thoughts on this topic. If you are using either Flow or TypeScript already and you are happy with your current setup, this article might be review, but also, please leave a comment to share your setup and experience. If you are not using static type checking in your React project, allow me to advocate that you can substantially reduce your development costs by using one.
Flow and TypeScript are both fantastic ways to limit technical debt in your JavaScript projects, allowing you to, among other things, evolve your codebase with confidence. I always try to put the maximum pressure on static code analysis. I use types as a single source of truth between different components of my apps. Every time I stumble over a bug, I ask myself: “Could this have been caught by static analysis?” Type safety is also one of the reasons why I prefer React over other frameworks such as Angular or Vue. With JSX, we have a unified type system across the logic of the application, its styling, and its presentation. The same level of type safety doesn’t seem to be available with other libraries.
So JavaScript type systems are awesome. But should you use Flow or TypeScript?
The Dilemma
If you are building a React project, TypeScript is a bit more of a natural choice: it has a great integration with create-react-app and material-ui (a go-to library for UI in React apps) has first class support for TypeScript. In React Native, Flow feels more natural. Expo is implemented with Flow and as far I know create-react-native-app doesn’t have great TypeScript support.
For a while I wrote React projects in TypeScript, React Native projects in Flow, and everything was love and all was well.
However for a new React project, I considered using Flow. This would enable me to keep consistent code styling and linting rules across all of my codebases. Moreover, support for React in both TypeScript and Flow is becoming more and more sophisticated, and it could be good to develop a strong expertise in only one of the two type systems. I started to develop a strong Flow type definition for material-ui here and I could really use some help 🙏🏻.
Below is the list I compiled while thinking about this problem.
Flow: Pros & Cons
Pros
- Eslint plugins 💄: Eslint plugins for React and React Native provide valuable static analysis and seem to be superior to their tslint counterparts.
- Mission statement 💂🏼: The original goal of TypeScript was to provide modern JS features as well as static typing. Now JS has caught up nicely with the modern features and TypeScript is only considered as a type system, which is what Flow is.
- Premium React support ⚛️: There are three aspects that make Flow support for React. Firstly, the React type definitions from Flow are a bit more precise than TypeScript. You can easily type component children. And type support of higher-order component is impeccable. Secondly, TypeScript’s main flavor is OOP whereas Flow’s flavor is functional. And React’s main flavor is functional: components are built through composition not inheritance which makes Flow a great fit. Last but least, Flow is a Babel plugin which most React project already integrate in their build system.
- Easy integration & automated refactoring 🤖: Since Flow is based on Babel, it integrates very well in a variety of toolchains. I might never need to do it, and it might sound a bit far fetched, but if it’s based on Babel, you are able to build automatic code refactoring for your projects.
Cons
- Crazy version changes 😱: Changes from one version of Flow to the other can sometimes feel a bit overwhelming. This is probably due to the project being much newer than TypeScript… …and the “move fast and breaks things” motto from its parent company.
- Undocumented features 📚: Not all utility types from Flow are documented. This might be fixed soon though.
- flow-result-checker 🤨: This is a somewhat big one. Flow doesn’t provide the ability to silence type errors from node_modules, which are errors you have no control over. It makes sense that the default behavior should report all errors, but there should be a flag to silence them. There is a very useful package named flow-result-checker that does exactly just that, but it is not usable with the most recent version of Flow because its reporting format has changed.
- Implicitly any in type definitions 🤦🏻: I noticed a case when writing a library definition where type imports are implicitly treated as any instead of throwing an error (if the import is done outside the module declaration). This is a bit scary, because you might think that your code is being type checked when it’s not. Hopefully library definition is the only situation where this can happen.
TypeScript: Pros & Cons
Pros
- Larger community 👨👨👧👧: Because it is an older project its community is larger. But this doesn’t necessarily mean that Flow won’t catch up. Currently, the quality of the TypeScript libraries definition is an order of magnitude higher than the ones written in Flow. IDE support seems to be better in TypeScript. Personally, I’m using Atom IDE so it hasn’t been a factor for me.
- Faster than Flow 🏎: TypeScript is much faster than Flow and doesn’t seem to consume as much battery life as Flow when working on your laptop.
- Upfront compile errors 🚨: This can probably be configured in both TypeScript and Flow, but having upfront compilation errors instead of a non mandatory type check seems to save time when testing your code by preventing you from running code that is bogus anyways.
Cons
- Lesser React support ⚛️: React support is not as good in TypeScript as it is in Flow, especially when it comes to creating higher-order components. This might change in the future however.
What are your thoughts on this?
Do you agree with this list or have a suggestion? Leave a comment! I’m looking forward to hearing your thoughts on this.
Shameless plug: Are you looking for a premium React Native starter kit? You should checkout React Native Elements.
