Flow vs TypeScript in React?—?My two cents
Hello, I'm Andrey Okhotnikov - CEO at React-Outsourcing. We are engaged in outsourcing web development , and in my spare time I help professional developers become even more professional.
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.
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.
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.
- 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 definition ?????: 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. IDE support, for instance, 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.
If you need help on web development on the react - write to me, I will be glad to help
If you want to always be aware of what happens in React - subscribe to our page. 5 times a week I publish an article on the hottest topic.
Our team is always open to cooperation, we are ready to outsource the development of interesting products. Just write to me. Have a nice day
Site: https://react-outsourcing.com/
Email: [email protected]