Switching from flow to TypeScript

12/2/2018

Recently I've made the switch in several projects from using Flow to TypeScript, and I thought I would write down a few of the reasons why.

1. Flow was hard to keep up to date

In one project we were on flow version 0.50 (at the time of writing 0.87 is out), every time we tried to upgrade we suffered broken changes. This got worse and worse as time went on, meaning we were less and less likely to upgrade. This is partly our own fault for not keeping our dependencies up to date, but also partly due to the fact flow isn't a v1 tool, and that we shouldn't have relied on it being such.

2. Using Flow felt like a chore

I saw over time, developers would treat flow like they treat a linter, only correcting things when there was an error in build, rather than constructing types as they went along. This suggested that my team weren't in favour of using flow (or maybe even a type system at all)[1]. If you only run type checks, after you have a feature working, it becomes a pain to go back and correct errors, even if they may be legitimate errors. This then encourages poor type checking or laziness.

3. Poor community support

Quite often it was difficult to get accurate types for third party libraries, and we regularly had to write our own, which then led to further problems with accuracy. TypeScript's community involvement seems to be a lot higher, and so far I've not faced any issues with type information with external libraries, finding that may other libraries are even written in TypeScript.

4. Strong type checking

This may not be entirely accurate phrasing. However, as TypeScript code can't run unless it compiles successfully it encourages writing correct types as you go, rather than after completing work. This results in fewer errors, and actually less time spent debugging, than if the code is written in Flow/plain JS (this is purely anecdotal).

These are just a few of the reasons as to why I've switched over a few of my projects to TypeScript recently, and is certain not an exhaustive list.

1 Turns out my team did like typechecking, but would not run it alongside their editing, so would often forget. ↩