Use of ES6 + Flow instead of TypeScript

Viewed 3814

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.

2 Answers

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

Related