React - using TypeScript vs Flow vs?

Question

I'm currently learning React and I think I understand it pretty well. However, there's one thing that's been bothering me regarding development of robust React applications - what tools do developers use for static type checking?

I really like TypeScript. I think it reduces the pain of developing JavaScript applications quite a lot, thanks to type checking and other neat features. Visual Studio Code also offers a really nice code completion. And I know that I can make it work with React by using typings + DenifitelyTyped.

The thing is, there aren't many tutorials about using React + TypeScript. There also doesn't seem to be many articles about developing using this combo. On the other hand, many people seem to be using Flow, which is a project backed by Facebook (and I guess they also use it).

I've managed to find a discussion on Reddit with pros and cons about going the React + TypeScript / React + Flow way. However, to me, it appears to be quite outdated as it is about 10 months old now. I think a lot has changed since then.

I've also found two articles about using React + Flow and React + TypeScript. The author states some issues he's run into when using both of the options and concludes that TypeScript is "the best bet right now" (November 2015), especially because the Flow project has many issues and receives low developer activity from Facebook. He also mentions it doesn't play well with Babel?

So, I guess the question would be: Is it safe to use the React + TypeScript combo, or will I run into some difficulties? What about Flow? Are there some other similar tools I should check out? Which approach would you recommend?

Update September 2017:

Having more than a year of experience with daily use of TypeScript, and playing with Flow for a while, I've came to the following conclusions:

• TypeScript is still painful to use to this very day. The problem is that the JavaScript world just moves so fast that TypeScript keeps lagging behind. Thinking about using that fancy new ES7 stage 3 feature? Nope, you can't. Wishing to get type hints for the latest version of some library? Wait a month, or two, maybe more...
• Flow has come a long way, it has been improved a lot, it can catch some things that TS can't. Best of all, it finally works on Windows. Also, there's great plugin for VS Code (no idea why it has only 3/5 rating). And it works 100 % with React Native, TypeScript is not even 50 % there yet.
• Most of the time, you don't need types at all. All the additional typing is rarely worth it. JS is a dynamically typed language, get over it :)

TL;DR: If you plan to use any type checker, I recommend using Flow.

Update February 2019:

I believe the recommendation above got out of date and is no longer relevant. Three reasons:

• React Hooks are here. They make type-checking your code much easier. In most situations, no additional code is needed.
• TypeScript's type inference has improved.
• TypeScript has much bigger community than Flow. Even yarn, Facebook's package manager, is moving away from Flow, to TypeScript.

So, I think TypeScript is a much more pragmatic choice than Flow in 2019.

As to whether it's even worth using any type checker at all, I'd say it depends on the project size. Small projects probably don't need it.

Digressive

You can also just use plain javascript and React offers you propTypes so that way you can make sure props are the correct type and are passed if required. – Epenthesis

Yes, I know about propTypes. However, that solves the issue only partially - in the view layer (if I'm not mistaken?). What about the code in stores and actions? I'd like to have static typing there also. – Digressive

blog.wolksoftware.com/working-with-react-and-typescript seems like it has some good documentation about using typescript with react and the different extensions you need to use – Epenthesis

Thanks for the link to the article! I've seen it in the past, but I think that the author goes over things just too fast (especially for those like me who have just started with React). Nevertheless, looking at the article for the second time, I discovered a link to an excellent article and I strongly recommend reading it if you want to use the React + TypeScript combo like me. – Digressive

Thank you for continuing to update this 3 years after posting. Worth noting that ts is supported simply now with "$create-react-app <project-name> --typescript" – Jollanta

This is truly a great post. Thanks for updating your initial findings. – Abortion

And thank you for keeping your initial findings in the post. The historical perspective of those systems having to keep up with ES in a particularly turbulent phase at the time is good information if we figure it informed design choices (e.g. focus on light annotation and heavier inference to compensate). Of course anyone can determine whether that's still relevant today or not, and thus whether those design choices still make sense or not (if all signatures are annotated, are in-body inference capabilities comparable?). FTR I've been favoring flow and am now trying to warm up to TS. – Piquet

Answer 1

I'm going to start this answer saying that I have never used Flow, so I can't say much about it. But, we are using React and TypeScript at work and it works great.

We have all the benefits I imagine you already know about, like refactoring, type safety, autocompletion, etc.

Sure, for what I have seen, the Flow syntax is cleaner than TypeScript, but you can add your types using TypeScript incrementally. I think, this is more a matter of taste. Some people prefer to have the code explicitly typed, others prefer to type less and have a stronger type inference.

About, the technologies I'd say TypeScript is a safe bet, Microsoft is pushing the language (there will be a version 2 soon), Angular is using it as well and there are a lot of Angular developers. Even here on SO, the tag TypeScript has more than 4K followers and it's rare to have an unanswered question.

The big issue with TypeScript, at least for us is that from time to time, we decide to use a component or a library that does not have the type definitions, so we have to create them ourselves. But I guess, that's a way to contribute back to the community.

Manicure

Answer 2

I just asked myself the same question (though not with React) and found the following articles useful in evaluating the two:

• http://michalzalecki.com/typescript-vs-flow/ (2016-07-15)
• https://blog.wearewizards.io/flow-and-typescript-part-2-typescript (2015-11-20)
• https://blog.wearewizards.io/flow-and-typescript-part-1-flow (2015-11-13)

The approach taken by the flow designers feels more functional with better type inference and a better approach for nulls. However, TypeScript has better community support especially with respect to pulling in types for third party libraries via http://definitelytyped.org/ which is important for having types flow through all your code for maximum type safety. TypeScript is created by Microsoft which has a rich history in writing compilers and evolving the technology in favorable directions - notable here is C# and the fact that they are already adding non-null types (2016-07-11): https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

TypeScript seems like the safer bet today.

And for those trying TypeScript out in an existing codebase I found the following settings in my tsconfig.json file really helpful in allowing TypeScript to co-exist nicely with JavaScript (allowing transition one file at a time):

{
    "compilerOptions": {
        "allowJs": true,
        "isolatedModules": true,
        ...
    }
}

Timepleaser

Answer 3

In my React development, I have quite a complex Babel / Webpack / Flow / Mocha toolchain set up and never had any issues with Flow. Takes some effort to set everything up (Webpack can be daunting at first), but afterwards, it just works. Flow is definitely the way to go as it is a narrower and more focused technology and as such more likely to play well with other tools. In contrast, TypeScript tries to be a lot more than just a type inference / static type checker tool and so it brings additional baggage and assumptions. So React is a specialized tool that does one thing well while TypeScript is effectively a language layered on top of JavaScript. To make sure Microsoft drives its point home, TypeScript files customarily have a different extension as well (.ts instead of .js) because you are now using a different language, got it?

TypeScript uses code generation to spit out JavaScript whereas in Flow the annotations are simply stripped off, there's no code generation as such. In the past, the Microsoft people promoting TypeScript used to make a statement to the effect that code generation is "file-local" (I don't remember the exact terminology used). This was supposed to provide a soothing reassurance that the TypeScript compiler isn't doing anything too magical. At any rate I can't find that statement prominently displayed any more. With Flow you don't need such assurances as you write in plain JavaScript (or whatever ECMA version you've configured Babel for) and the annotations are, like I said, simply stripped.

Not to mention that TypeScript is coming from a company that specializes in unethical and questionable technical practices (I don't rule out that TypeScript may eventually turn out to be the Mother of all Embrace-Extend-Extinguish ploys). Let's not forget that Microsoft did everything in their power to cause Javascript to fail as they (rightly, if belatedly) foresaw what a threat it represented, and still represents, to their crappy operating system and their bloated office suite.

Additionally, Flow's type system was much more powerful last time I bothered to evaluate TypeScript (circa 2015) and it was much easier to apply it incrementally or even sporadically in the sources. For integrating third party libraries I am using flowtyped and it is very rare that I need to complement those found there with my own definitions.

Finally, the fact that Angular uses TypeScript means absolutely nothing as Angular is not really relevant for new projects. React has won hands down, time to move on.

Wamble

"a company that specializes in unethical and questionable technical practices" - and Facebook doesn't? :P – Nidify

The post is strongly opinionated (there's a good reason why 'vs' questions are off-topic on SO). As for extensions, flow-typed .js is not valid JS, so I'm not sure if keeping same extension is a good thing here (not to mention that TS is a replacement for Babel+Flow toolchain, not Flow alone). much more powerful - is worth a clarification. Angular is not really relevant for new projects - how so? Just because you're in React boat doesn't mean that everyone is. The frameworks are really different, have strong and weak points, gained a lot of momentum and have been going head to head on SO. – Atrocity

Answer 4

If you want type checks but would prefer to keep plain old javascript (to avoid compiling, or for portability, etc), here's one important distinction between the two (for React or in general):

• With Flow the initial setup can run static analysis on vanilla js (it infers many types):

  function square(n) {
    return n * n; // Error!
  }
  
  square("2");
  

• With TypeScript there's a migration effort and only some vanilla js static analysis without it:
  • noImplicitReturns which prevents you from forgetting to return at the end of a function.
  • noFallthroughCasesInSwitch which is helpful if you never want to forget a break statement between cases in a switch block.
  • TypeScript will also warn about unreachable code and labels, which you can disable with allowUnreachableCode and allowUnusedLabels respectively.

More Benefits To Flow

Flow's Comment Types and Error Suppression take support for vanilla js a step further, by allowing you to gradually incorporate type checks through legal js comments that annotate the type or suppress specific checks you might not be ready for yet. Comment types have been a feature request in TypeScript for quite some time, and only recently has there been a PR for it (see previous link).

Downsides To Flow

That said, all of Flow's simplicity does come at the cost of some pretty complex configuration with some annoying caveats, like how it type checks 3rd party libraries, etc. The best advice someone can give about Flow: try to cross-reference anything you read in their documentation as it's outdated and in some cases can be a little misleading.

Jipijapa