TypeScript vs Flow with React in the background

Consider this scenario. You’re a web developer and want to build this awesome website of yours. You know, portfolio, blog, showcase, whatever. But, as you’re the best there is 😅, it can’t be just a standard HTML + CSS + JS combo. No, no! You know you can do better than that. So, driven by [put your React-related emotion here 🙃] you choose React as the best tool for the job. And then, as you’re about to swap in TypeScript - your go-to language for type-safe JavaScript, you stop. Contemplating the superiority of .js extension over .ts you start to look for an alternative. And an alternative you find - Flow. This way - you - encouraged by the nice logo and landing page 😂, or by hype you’ve stumbled upon somewhere on the web, you decide to go with the Flow. 😉 But you later change your mind. And again, and again… And that’s how our journey begins…

Versus

So, the story above might not be completely real, but I thought it would be nice to provide some context. 😉 I indeed have been in a similar situation before, but after typing just a few LOCs, my choice was obvious. But I know that there are some that still struggle with choosing the right tool. Maybe you’ve just starting to discover the potential behind static type checking in JavaScript or you’re looking for an alternative to your current tool? If so, then there are high chances that you’ll sooner or later meet TypeScript and Flow. And, most likely, that you’ll have to decide which one to choose. That’s why this article exists, to help you made your own choice. Now, let’s take a closer look and compare these two, with React web app development in mind. Enjoy! 🎉

TypeScript

TypeScript is a typed superset of JavaScript. So, basically a fully new, compile-to-JS language. Because it’s syntax is ES-Next compliant (when not considering types) it can be easily taken as a tool for providing type-safety to your JavaScript code. What else to consider? It’s backed by Microsoft and has a pretty big, growing community behind it. It’s possibly one of the most mature options out there for writing typed JS. There’s plenty of tutorials and guides out there to learn, including official docs which are well-written and cover most important aspects of the language. It has very good IDE support. In fact, you can thank TS for powering the most popular editor among web developers - VS Code! Provided autocompletion is fast and reliable, so everything’s fine here. TypeScript also provides a way to type your JS code without changing it directly through declaration files. And, because of the community, there’s a lot of these type declaration for a number of popular JS libraries.

Flow

Flow in opposition to TypeScript isn’t a superset or language. It’s a static type checker for JavaScript written in OCaml. Thus, it doesn’t provide any other functionalities than type system. And, because it’s not a language, it can be smoothly integrated with JavaScript with a single comment annotation. Besides, if you don’t like types, you can write them in form of JS comments (although this can be tiresome and TS in newer version supports similar, even better solution based on processing JSDoc comments). It’s developed by Facebook and has nice-looking logo and website (details are important 😅). But, there are some drawback tho. Its docs, for example, even if they look better, they’re not well-structured and can be hard to read and understand (IMHO). Going even deeper, its community is much smaller than that of TypeScript. It means there are fewer tutorials, online resources and library definitions (Flow provides a way of typing legacy JS code with outside files too). It has support in many IDEs built-in and/or with plugins. It can provide good autocompletion and code suggestions, but they don’t feel as fast and reliable as ones of TypeScript. But let’s remain unbiased and compare features set of these two tools.

Features & differences

In terms of features, both Flow and TypeScript might seem incredibly similar. And, in fact, they really share a number of features and syntactic relations. That’s good because at any moment while trying out any of these, you can always switch with ease. But, there are some aspects and custom addition that differ these two, and that’s why you’ll have to make a choice after all.

Starting with the basics, TS, as well as Flow, cover them pretty well. Basic types (primitives and literals), classes, interfaces, function types, tuples, unions, aliases, generics and infamous any types are handled generally in the same way. What differences Flow is its vast collection of utility types. They allow you to operate on other types to fulfill a number of different scenarios. It’s something that TypeScript is lacking at (but it’s worth noticing that it’s improving with time).

Then we have the export syntax. In TypeScript you can import/export any existing type just like you would do with any other JavaScript construct, using ES6 modules syntax. In Flow, on the other hand, you have to use import/export type syntax. It might not seem like a big deal, but it can very much alter the way you think about your code. In TS you don’t have to think if something is a type or not when handling modules. In Flow, it’s just completely otherwise. Also, in Flow, you can use typeof operator while importing to import the only type of given value.

There’s also a small difference when it comes to method overloading (redeclaring your function/method with different parameters and/or return type). In Flow, it’s only available in definition files, the fact that is left undocumented. In TypeScript, you can use it freely everywhere in your code and declarations.

Next, in TypeScript inside classes, you can use accessibility modifiers, i.e. public, protected and private. It’s something you won’t see in Flow. For me, this feature is incredibly important, even if it does translate just to standard JavaScript without any changes (e.g. you might want to have your private properties begin with an underscore). That’s probably why Flow doesn’t support this - it just wants to be fully compliant with JS.

There are some smaller and bigger differences. Types variance, structural and nominal typing are probably the most important ones from them. But this is a bit more complex stuff and you won’t notice it until you’ll start doing some real typing. You can discover the rest of the differences on your own or by taking a look at this comparison table.

Support & community

This category is really important. I think that the amount of support that specific product receives from its users is a decisive factor when it comes to its survival. Here the things are simple - older, more matured TypeScript has a bigger community than Flow which is younger and has some performance issues. But let’s dig deeper! 😉

What we have with TypeScript is a well-established ecosystem with Angular and alike based on it. You have more type declaration (even whole collection) and great tools based on it (VS Code). The performance is great and snappy. It’s in active development and is growing in its popularity rapidly.

With Flow situation is a little different. The community is smaller and thus the support is lacking. Of course, it’s in the very active stage of development. Even going to the level where different versions require significant changes (which isn’t too good either). The collection of library definitions is smaller, but there are some clever ways to make it bigger and better. I can say that Flow recently has gone through some internal changes which are reflected in its new roadmap. That’s good. Maybe there’s a bright future waiting for it somewhere, sometime.

Lastly, I can compare landing pages and official documentations of both products. I omit the fact that TS has some very good guides written by the community. I’m only looking on the official stuff. And here you can definitely see that flow has a nicer logo and website. 😂 It does a good job of encouraging you to use Flow. TypeScript has a good website and logo too, but these aren’t really, you know, special. Sadly, the docs for Flow aren’t as good as their design - they lack description for some features and are sometimes unclear.

Setup

By using the word setup, I mean your development tools. With TypeScript your files have either .ts or .d.ts (declaration files) extensions. You can process your files with either TypeScript compiler or other tool, e.g. Babel plugin. Keep in mind that when you’re not using the compiler, you’re just striping your code out of types, without checking for any errors and etc.

When using Flow, which to remind you is just a static type checker, your workflow looks differently. All your files should have .js or .js.flow (definition files) extensions. You can check your code using provided CLI tool, or relay on IDE integration to do it for you. To actually process your code, you have to use Babel and a proper plugin to strip the types from your code. That is unless you’ve written your types in form of comments but, I think it’s not so good idea anyway.

React

So, as the final category, let’s consider the workflow with React for both of our tools. In fact, this is where Flow can really shine. Just like React, it’s developed by people from the same company, so you would expect to integrate well (or even better) with this particular library. And you won’t be wrong. Flow has indeed advanced, built-in support for React. You just have to add JSX plugin to your Babel config and you’re ready to go. It has really good support for all features you’d expect - components, HOCs, context, refs and even Redux itself! Also, if you’ve seen Flow’s roadmap, React support is meant to get even better, so stay tuned for that!

Now, let’s get back to TypeScript. Some might say that the support for React is worse here than in Flow. But, I wouldn’t agree with you completely. TS has indeed lacked good support for React for some time, but these times are long gone. In TS compiler you have built-in support for JSX syntax with a special option for React. React typings aren’t an integral part of TS like in Flow, so the may not always be up-to-date with the latest versions of React, but I think this can apply to Flow too. Nonetheless, they are well-written. I can say that I enjoyed using React and Redux with TypeScript for one of my projects. There might be some issues with HOCs and Redux connected components but it wasn’t that hard to overcome (for me at least). I can safely say that support for React in TypeScript is very much matching the one in Flow.

Final word

So, above I’ve compared some aspects from both of these productivity tools. It’s time for a conclusion then.

As for the recommendation, I can safely say… it depends. 😛 There isn’t a single way that will work for everybody. I personally use TypeScript and I’m fine with that. Even in React-specific workflows, it is great for me. The IDE support for it is just outstanding, and the performance…

Flow can work well too! Maybe you need some of its utility types that TypeScript doesn’t have or you want even better integration for React (if the one in TypeScript is not enough). Flow may not have the same support, community (size-wise) and performance as TS, but as it is still a younger project, I guess we (or at least I) will see where it goes in the nearby future.

That’s all for this article. If you find it good, consider sharing it with the round buttons below and sign for notification with the belly on the right. Also, follow me on Twitter and on my Facebook page for more up-to-date content. 🔥