I'm modeling a JavaScript app. The main feature of this app is to consume a REST API to configure and show forms with some custom input types. I'm thinking of use TypeScript to take advantage of types and classes. But after some Google searches I realized that I can reach a very similar result with JavaScript ES6 + Flow (and Babel maybe).

My questions are:

• These two approaches are really similar or I'm making a mess?
• What I should consider to make a good decision choosing between ES6 + Flow or TypeScript?

Thanks for help.

I'm modeling a JavaScript app. The main feature of this app is to consume a REST API to configure and show forms with some custom input types. I'm thinking of use TypeScript to take advantage of types and classes. But after some Google searches I realized that I can reach a very similar result with JavaScript ES6 + Flow (and Babel maybe).

My questions are:

• These two approaches are really similar or I'm making a mess?
• What I should consider to make a good decision choosing between ES6 + Flow or TypeScript?

Thanks for help.

• javascript
• typescript
• ecmascript-6
• flowtype

• 1 I can't help but feel that this question will be primarily opinion based. I personally use Typescript for everything, and with TypeScript's // @ts-check (new in 2.3) it can work much like Flow as I understand it from the project homepage. However, not having used Flow myself, I can't really tell if a good comparison can be made. – Gerrit0 Commented May 12, 2017 at 16:37
• 2 I don't think this is primarily opinion-based. It's certainly toeing the line, but the questions are concrete. It is "what should I consider when choosing," not "which one should I choose." – Nat Mote Commented May 12, 2017 at 16:54
• 3 Both Flow and TypeScript are ES6+. So really you are comparing Flow + Babel vs TypeScript. – Aaron Beall Commented May 12, 2017 at 17:05

2 Answers 2

Disclaimer: I work on the Flow team.

In general, I believe that Flow is more focused on soundness, while Typescript is more focused on ease of use. As such, Flow will disallow things that could cause runtime errors, while Typescript, in some cases, decides that in practice, certain behavior is not likely to cause an error, and preventing an unlikely error is not worth the inconvenience to the developer.

Here is a concrete example:

type Foo = {
    x: string;
}

type Bar = {
    x: 'foo';
}

const b: Bar = { x: 'foo' };

const f: Foo = b;

f.x = 'asdf';

This code is incorrect -- b.x is now 'asdf' even though the type says that it should be 'foo'!

Typescript allows this. Flow complains with a confusing error.

(typescript playground) (try flow)

With regards to tooling, Typescript wins, hands down (as much as it pains me to say it, as the person primarily responsible for integrating Flow into Nuclide). The setup process is simple and things just work. For Flow, you need to install and configure Babel (since Flow is not a compiler, you need something to strip out the types). For Typescript, all you need to do for editor support is download VSCode and you are done -- you don't even need to download Typescript separately. For Flow, if you want to go the recommended route, you need to install Atom+Nuclide and download Flow separately. Once you are set up, the Flow editor support works quite well, but the initial setup is time consuming.

I haven't used VSCode+Typescript enough to be able to accurately compare them but I do know that a lot of people are very happy with it, and based on my limited experience with it, it is very polished. The feature set is larger, too -- for example, Typescript supports automated refactoring.

Typescript's DefinitelyTyped (a set of type definitions for libraries, so you can use npm modules while retaining type safety) is larger and more mature than Flow's similar flow-typed -- although flow-typed is growing.

Statically typed systems help

I'm a big fan of statically typed languages, in particular Haskell. I have dabbled with both TypeScript and Flow. The draw to a statically typed technology is to build better code with the help of a compiler (or some equivalent). With improved validation tools, I can clarify my thinking to get to a more sophisticated, more self-evident design. This is a quality of the code that also pays off when it comes time to refactoring and maintenance. That's the benefit.

The cost is where the choices differentiate themselves the most

In this choice, cost is where the rubber hits the road because this is where the biggest differences between Flow and TypeScript appear. What makes Haskell powerful is the ability to infer the types. While it is a best practice to annotate the function definitions with a type signature, it is not required.

Furthermore, and this is key, I lean on the type inference engine the most while writing the code, i.e., while trying to figure out the best way to design the type signature. Once I have code "that types", I actually don't need the statically typed capacity... job done, per what the compiler compiler does by stripping all the type information away.

Given when I need the statically typed information the most, the inability to infer types was the biggest issue I experienced with TypeScript. When I needed the type capacity the most, I could be inadvertently baking in mistakes without any guidance on how to resolve it when I most needed it. Furthermore, by not having the option to let the compiler infer the information, I increase my workload, I increase the complexity of the problem in ways I know are unnecessary. That's where an inference engine is key; it reduces the user having to be explicit. It enables a linear process while designing my code (cause and effect).

Punch line

The source of the benefit is well defined (types help). How much benefit likely depends on the project. In my experience, there are more projects where the benefits outweigh the costs of using a statically typed approach using Flow.

Regarding the setup of Flow, I was already using a transpiler and found the extra configuration required to be nominal. The benefit of this configuration approach is the ability to incrementally use the technology, and within the project only where you think you need the type-driven "guidance" the most.

Finally, I have not mentioned the syntax benefits of using Flow. It's bad enough I'm having to track various flavors of JS (all good changes), using Flow I avoid what I consider a large departure from JS for TypeScript.

- E