TypeScript vs Flow

This is not a strict comparison, more like a reflection. To me, Flow and TypeScript are same-ish, both not ideal yet better than typeless JavaScript. They are different in many aspects, yet similar for simple use cases.

I'm doing a small experiment with Redux, type system, Finite State Machines, side effects etc. I wanted to try out io-ts, it has type definitions for TypeScript (it is actually written in TS), but not for Flow (they were deprecated before v1). It is possible to update old Flow definitions, but I decide simply to rewrite the application in TypeScript. This post is basically a reflection on the process.

react-scripts-ts

react-scripts-ts comes with tslint instead of eslint and it is configuration is exposed, which is against Create React App philosophy because it supposed to be zero-configuration setup.

Default tslint configuration is too much opinionated. It asked me to sort properties alphabetically. Seriously who has time for this? I want linter to point out footguns, it supposes to help not to make more work for me. I like CRA approach, eslint points some definite errors and formatting is left for prettier.

Linter errors appear as errors, not as warnings. Sometimes those errors "get stuck" - I get into an error state, then I fix it, but the error doesn't go away until I restart the project. I have to disable most of tslint configs, it was an unpleasant experience. And I don't want spent time configuring it, I just want to do some prototyping.

It seems, but I haven't actually measure it, that response cycle (time between I hit save button and changes propagate to browser) is slower than CRA with Flow. Not sure if this due to TypeScript or tslint or react-scripts-ts.

Actually TypeScript vs Flow

While I'm on it. Some people tend to compare TypeScript and Flow. I can't express how same-ish they are to me. I'll explain why - I have this internal dialogue about TypeScript and Flow:

• Flow is built around the idea of soundness, where is TypeScript is built around the idea of "practical" type system (I actually do not buy this idea, it seems they just don't want soundness)
• Yes but Flow have errors in implementation, so it wants to be sound, but actually, it is not. If you want soundness use ReasonML (Ocaml). Also, Flow sometimes gives up type checking, there is so-called uncovered by types code regions and you need to use flow-coverage-report
• Okay, but flow have all those utility types, like $ObjMap, $Call etc.
• Yes. TypeScript added a lot of this too recently. See utility-types and flow-to-typescript
• Yet it is not possible to implement $ObjMap in TypeScript
• Who cares. It is not possible to have exact strings and exact object types from literals

const a = "b";

• In Flow type of a is a string, in TS it is "b" string literal (and it is not possible to do a[0]="c")
• I heard that exact object types are coming to Flow
• Finally, they copied it from TypeScript
• And TypeScript copied the idea of typesVersions from Flow, now we need to wait until this idea will be copied back to flow-typed
• Facebook uses Flow, so React is a natural fit for Flow, where is in TS you need to do some tricks
• Okay, but TS also have the biggest number of type signatures
• And we can use some flowgen to convert it to Flow
• Flow has idx
• TS has monocle-ts, io-ts and many more
• TS has compiler flags which are a bad idea because each project will have a different flavor of strictness. Same applies to type signatures, you never know how strict they are.
• TS has a bigger community and more open development cycle. Flow development happens behind the closed doors

And this dialogue goes on and on. So I decided for myself that Flow and TypeScript are same-ish. Both are not sound, both are not ideal. Yet I would choose TypeScript or Flow over plain JavaScript.

Don't get me started about ReasonML/BuckleScript

Photo by Matt Jones on Unsplash

This post is part of the series. Follow me on twitter and github.