John Au-Yeung I'm a web developer interested in JavaScript stuff.

TypeScript alternatives: TypeScript vs. Flow

6 min read 1779

JavaScript is a dynamically typed language. This means that data types of variables can change as we assign different values to them.

There’s no built-in way to annotate or restrict the types of variables. Therefore, we need to write our programs in another language and then transpile it to JavaScript if we want that capability. We need a language that’s a typed extension of JavaScript to check and restrict the types of our variables.

There are two typed extensions of JavaScript: Microsoft’s TypeScript is arguably the best-loved, and Facebook’s Flow has emerged as a TypeScript alternative. In this article, we’ll look at and compare the features of each of these.

TypeScript Flow
Developer Microsoft Facebook
First released October 1, 2012 November 18, 2014
License Open source Facebook
Community Large Small

TypeScript vs. Flow: Developer experience

The developer experience can be measured using various scenarios, including support by various libraries and frameworks, ease of use, and overall productivity. The full documentation of TypeScript can be found here and the full documentation for Flow can be found here.

From the support perspective, TypeScript is much better because major frontend frameworks like Vue, Angular, and Facebook’s own React all support TypeScript out of the box. For example, we can build a Vue project with TypeScript by choosing the TypeScript option from the Vue CLI.

Once we chose TypeScript, then we can configure it to transpile to JavaScript, (usually ES5) to maximize the support of browsers.

Then when we reference Vue when creating our component we’ll get TypeScript type inference:

import Vue from 'vue'

const Component = Vue.extend({
  // ...

Also, with Vue, we can write components with TypeScript in its own special way with classes like this:

  <button @click="onClick">Click!</button>

<script lang="ts">
import * as Vue from "vue";
import { Component } from "vue-property-decorator";

class App extends Vue {
  public message: string = "Hello World";

  public onClick(): void {

export default App;

We can see the familiar JavaScript syntax with some TypeScript annotations. For example, Angular is built with TypeScript and it uses TypeScript almost exclusively. There was an option to write Angular apps with plain JavaScript but it never caught on.

On the other hand, Flow is only supported by React. According to this document, we can use Flow with React, we just have to add Flow support in the Babel configuration to enable support for Flow with Babel.

We made a custom demo for .
No really. Click here to check it out.

To add Flow support, we just run:

npm install --save-dev @babel/preset-flow

and add:

  "presets": ["@babel/preset-flow"]

to the .babelrc file.

The syntax differences between Flow and TypeScript isn’t significant. They both support similar types like the usual JavaScript data types, literal types, union types, conditional types, etc. Also, both TypeScript and Flow use similar syntax for type annotations.

Both TypeScript and Flow have operators and various utility types to preserve the flexibility of the JavaScript type system. For instance, the following is the same in both Flow and TypeScript:

function concat(a: string, b: string) {
  return a + b;

The function above takes two strings and then returns both concatenated together. They both have types for optional properties. TypeScript has the nullable type and Flow has the maybe type. Both Flow and TypeScript have generics, which we can use to write code that takes a variable type.

For instance, the following function takes whatever is passed in and returns the same thing:

function identity<T>(value: T): T {
  return value;

We can use it by writing:


Flow provides typecasting as does TypeScript. They work similarly. With Flow, we can cast a value to a related type by using the : symbol like this:

let value = 1;
(value: number);

The code above is Flow code to cast a value type 1 to a number.

With TypeScript, we can cast types using the as operator like this:

let value = 1 as number;

Another important feature that both Flow and TypeScript have are interfaces. Interfaces are used as types that restrict the structure of an object.

interface PersonInterface {
  firstName: string;
  lastName: string;
  fullName(firstName: string, lastName: string): string

This is code for an interface in both Flow and TypeScript. Then we can create objects and classes that implement the interface with the implements keyword in both Flow and TypeScript.

interface PersonInterface {
  firstName: string;
  lastName: string;
  fullName(firstName: string, lastName: string): string

class Person implements PersonInterface {
    firstName: string;
    lastName: string;
    constructor(firstName: string, lastName: string){
        this.firstName = firstName;
        this.lastName = lastName;

    fullName(firstName: string, lastName: string): string {
        return `${firstName} ${lastName}`;

The code above creates a class that implements the PersonInterface interface.

We’ll get an error with the Flow and TypeScript transpilers if we didn’t implement all the members listed in the interface.

One unique feature of Flow is that we can put our type checking code in the comments. For example, we can add comments for type checking like this:

function greet(greeting /*: string*/) /* : string */ {
  return greeting;

This isn’t available with TypeScript. However, this isn’t a big draw since comments don’t have autocomplete or syntax highlighting.

TypeScript has much better support with text editors. Editors like Visual Studio Code and IDEs like WebStorm have built-in support for TypeScript. As we can see from JetBrain’s website, WebStorm has built-in support for debugging TypeScript code and also checking it for errors. Syntax and compilation errors are displayed right in the IDE. Hints are available as we’re typing in code in WebStorm. Type checking with TypeScript is built into these programs.

Supporting TypeScript means that developers get full type checking, auto-complete, and compiler errors right on the screen of your editor even before building the code. TypeScript code has type definitions that are added to libraries to denote the types that the code has.

It also has a language server to check for these types. Flow checks types locally and doesn’t have a language server or type definitions like TypeScript. We need to run the Flow compiler to check our app, whereas we can check our JavaScript code with a TypeScript language server as we’re typing code into our files.

Type definitions are bundled with libraries like Lodash and moment.js so that we get autocomplete and type checking support in text editors that work with TypeScript like Visual Studio Code.

Developer experience comparison

TypeScript Flow
Editor and IDE support Widespread Little to no support
Questions posted on Stack Overflow 100000+ 600+
Framework support Many, including Express, Vue, React, Angular, etc. React only
Library support Many Few to none (that we know of)
Autocomplete Available in IDEs and text editors None
Compiler error detection Available in IDEs and text editors None
Syntax Comprehensive type checking, includes both static and dynamic type annotations Comprehensive type checking, includes both static and dynamic type annotations
Generics Supported Supported
Support in existing projects TypeScript package can be added to support TypeScript Add support with Babel


The performance difference between Flow and TypeScript is minimal. TypeScript consistently uses 500 to 600 MB of RAM and Flow isn’t too different. There isn’t much difference between them in terms of computing resource efficiency.

According to this Reddit thread, TypeScript is faster and less buggy.

Community support

Community support for TypeScript is much better than Flow, as we have already mentioned. Other than React, Flow’s support is sparse. Most libraries don’t support Flow.

Also, there’s little documentation outside of the official sources, and in Stack Overflow, there aren’t too many questions about Flow when compared to TypeScript.

As we can see from, there are more than 100,000 questions for TypeScript and from we only see a few hundred questions, and most of them have nothing to do with Facebook’s Flow. For instance, there’s also documentation for adding Flow support to a Create React App project.

Also, for plain JavaScript projects, there is documentation to install Flow support in an existing project via Babel. Many frameworks have support for TypeScript, including Vue, Angular, and React frontend frameworks as we saw above. Also, Node.js web frameworks like Express can have TypeScript support added. Nest.js is a backend framework that’s built with TypeScript support baked in, allowing us to use TypeScript for development without making big changes to our project.

For example, with Express, we just have to run:

npm install --save-dev typescript

to install the TypeScript transpiler.

Then we can add a tsconfig.json file to configure our TypeScript transpiler by writing something like:

    "compilerOptions": {
        "module": "commonjs",
        "esModuleInterop": true,
        "target": "es6",
        "noImplicitAny": true,
        "moduleResolution": "node",
        "sourceMap": true,
        "outDir": "dist",
        "baseUrl": ".",
        "paths": {
            "*": [
    "include": [

Then to install the type definitions for Express and Node’s standard library, we run:

npm install --save-dev @types/node @types/express

As we can see, it’s not too hard to use TypeScript with existing libraries since there are TypeScript type definitions for many libraries and frameworks.

For more type definitions for TypeScript, we can go to the DefinitelyTyped website.

As we mentioned in the developer experience section, editor support is way better with TypeScript. Visual Studio Code, Sublime, and other editors have support for TypeScript either built-in as with Visual Studio Code or available as a plug-in for Sublime.

Resources and documentation quality

TypeScript definitely wins in terms of the quantity, resources, and documentation available.

Since it’s supported by many libraries and frameworks, lots of people are using TypeScript daily. There is plenty of information about each feature in TypeScript, including examples and explanations.

Here are a few more resources

TypeScript playground supports different versions of TypeScript so we can see how our code acts with different versions of the TypeScript transpiler.

On the other hand, Flow only has some documentation and a short document on how to set up Flow with React. There are also a few posts about Flow here and here.


TypeScript is definitely the more widely used language that’s transpiled to JavaScript. TypeScript has more support than Flow does with libraries, frameworks, and it’s used more pervasively in apps because of that. They both provide very similar type checking abilities which retain the flexibility of JavaScript.

TypeScript and Flow both include all the built-in JavaScript data types. In addition, we can use it to define literal types, union types, intersection types, etc. to create more flexible types.

In addition, they both have interfaces to restrict the members that we can add to objects when they’re used to annotate the type of an object. For creating scalable JavaScript code, TypeScript is definitely the winner since no other alternatives have such pervasive usage and support.

Writing a lot of TypeScript? Signup for our upcoming TypeScript meetup to learn about writing more readable code.

TypeScript brings type safety to JavaScript. There can be a tension between type safety and readable code. Join us on Sept 30th at 2pm EDT for a deep dive on some new features of TypeScript 4.4.

Save your seat.

John Au-Yeung I'm a web developer interested in JavaScript stuff.

Testing accessibility with Storybook

One big challenge when building a component library is prioritizing accessibility. Accessibility is usually seen as one of those “nice-to-have” features, and unfortunately, we’re...
Laura Carballo
4 min read

6 Replies to “TypeScript alternatives: TypeScript vs. Flow”

  1. After writing writing a few reasonably sized applications with flow, I’ve got to say I’m a fan and haven’t run into many of the cons you list in the article (my IDE supports it, it has a decent community, and there are community-created types for popular libraries).

    For me, flow’s biggest benefits are that it’s easy add (can be done incrementally) and remove, and it works with every system out of box.

  2. I don’t know why people compare TypeScript so much with Flow. Both of them are great, for different teams. In 2017 we built our new frontend technology with Angular and TS but we encountered difficulties shortly, especially when it came to debugging Angular (we are mostly backend devs, inexperienced in frontend). But we found ourselves less productive in TS (even if it’s closer to the type system we are used to in Java) and didn’t even use it in a strict way, we couldn’t see the benefits to pursue it further. Because of that, at the end of 2019 we have adopted a new stack, React with Hooks and Flow. It’s just that it is more suitable for our team, the features are delivered faster, a good choice for our 3-man army on the frontend. I recommend people to experiment with both and please don’t disconsider Flow, it is pretty powerful. We got sold on the idea that TS is for Java devs, but this wasn’t true in our case. It could be in yours. Moreover, we are using IntelliJ for everything JavaScript and I have to say the Ultimate version has strong Flow support, didn’t let us down.

  3. “Flow checks types locally and doesn’t have a language server or type definitions like TypeScript. We need to run the Flow compiler to check our app, whereas we can check our JavaScript code with a TypeScript language server as we’re typing code into our files.”
    This is completely wrong. Flow has always been able to do the type checking in real time (look for “flow check-contents”). Same as TS Flow has plugins for popular editors and IDE’s ( which are using this API.

  4. A really biased comparison, this would seem to me. I have used both flow and TypeScript extensively and can concur with previous replies that:
    – Flow is easier to integrate incrementally into an existing codebase thatn TypScript.
    – It is well supported in Webstorm, PhpStorm and other JetBrain products. There are several good plugins for VSCode as well, and they can give real time flow checking too.
    – Community support is fine enough. To be honest, I’ve had more trouble finding solutions to TypeScript issues than I’ve had with Flow. But that may be personal.
    – The argument that libraries do not support it is a bit weird. Never looked at

  5. I agree with those above. This is a super completely bias comparison from someone who hasn’t put enough effort into flow to create a fair comparison.

    – React does not offer TS out of the box, but it does for Flow because React defs are built directly into the Flow base defs. I think you may be confusing React from CRA, which are two completely different things.
    – The licenses you specified can have the wrong impression saying that Flow’s license is `Facebook`? They’re both MIT
    – Your development experience comparison also shows the lack of research. Yes there are less libraries that are shipped with flowtype by default but just like TS, these are added to the flow-typed library.
    – Your tutorial for installation of Flow should have at least given instructions to install `flow-bin`. Which is the equivalent to the `typescript` package in flow world.

    For those who are reading the comments to learn more here are my 2 cents.
    I think it all depends on what you’re trying to accomplish and what your stack is. If you’re coming from a node or react background, flow may work for you.
    Flow’s main driving force is soundness, which helps you prevent runtime errors through type checking and statically analysing your code.

    Its focus is to prevent runtime errors but of course because it always compiles down to Javascript types can always be typed wrong as its done by humans, it doesn’t block compiling. In that case I recommend putting lint-staged so that you at least don’t comment code with flow errors.

Leave a Reply