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 | |
First released | October 1, 2012 | November 18, 2014 |
License | Open source | |
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:
<template> <button @click="onClick">Click!</button> </template> <script lang="ts"> import * as Vue from "vue"; import { Component } from "vue-property-decorator"; @Component() class App extends Vue { public message: string = "Hello World"; public onClick(): void { window.alert(this.message); } } export default App; </script>
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.
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:
identity<string>('foo')
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 |
Efficiency
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 https://stackoverflow.com/questions/tagged/typescript, there are more than 100,000 questions for TypeScript and from https://stackoverflow.com/questions/tagged/flow 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": { "*": [ "node_modules/*" ] } }, "include": [ "src/**/*" ] }
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.
Conclusion
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.
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.
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.
`flow` tag in S.O. has nothing to do with the Facebook library, as it was wrongly stated in this article.
For that purpose, `flowtype` is used:
https://stackoverflow.com/questions/tagged/flowtype
“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 (https://flow.org/en/docs/editors/) which are using this API.
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 https://github.com/flow-typed/flow-typed/tree/master/definitions/npm?
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.