Why I gave Flow a shot after TypeScript
UPDATE: Since this article was published a lot has changed. The majority of the issues I had with TypeScript have been resolved, and it appears that TypeScript has pulled ahead as the tool of choice for JS type checking. I’m even moving my own projects from Flow to TypeScript.
I must admit when I first tried TypeScript on a project I was skeptical. After all this is JavaScript we’re talking about — what the hell do I need types for? But after having used it on a large team project over the last eight months I’ve really come to depend on the stability types bring to a shared codebase.
But here’s the thing…that type safety came with some baggage as well. Here are some items I found to be a pain point with TypeScript:
- All your files use the
.tsextension instead of.js— it might just be me but this always felt dirty. - No easy opt-in option if you want to slowly introduce TypeScript into an existing project — felt like all or nothing. (Update: See Type-Checking JavaScript Files with — checkJs for a way to migrate an existing project to TypeScript)
- Tooling overhead —you may find that you need to add additional dependencies so your tooling can handle
.tsfiles. (e.g. unit tests)
These are some of the sticking points that led me to give Flow a try, and although it’s still early, I’m liking what I see so far, and here’s why…
Your files are still JavaScript
This may seem like a small thing, but at the end of the day you get to keep that .js extension, and all your files remain JavaScript. You only need ensure that Flow types are stripped from your files during your build. If you happen to be using babel this is as simple as adding babel-preset-flow to your .babelrc file.
Opting in is easy
Want to add Flow to an existing project, but want to do it in small chunks? No problem, all you need to do is add // @flow to the files you wish to use Flow in — that’s it!
Less strict with dependency type definitions
This could have been specific to my project’s configuration, but TypeScript would always complain about third-party libraries missing type definitions. This would then involve checking if a type file exists, and then installing it. This was extra painful when trying to convert an existing project with many dependencies, as you have to install these type definitions one by one.
Where I found Flow would simply ignore those dependencies that were missing type definitions. And if you wanted to add definitions it was super easy with flow-typed, which will automatically installs definitions based on your package.json. An added bonus — if a definition for one of your dependencies doesn’t exist inflow-typed it automatically stubs out a file definition for you.
Focused on static type checking only
Flow is a static type checker for your JavaScript code — that’s it. Not a transpiler, not a superset of JavaScript, just a type checker. It does one thing, and it does it well.
Great support
When I hit a few roadblocks during development I reached out directly to the Flow twitter account, and I was answered directly by Caleb Meredith part of the Flow team. This help was invaluable, and it was such a welcome surprise considering how busy these guys must be.
Want to give Flow a go?
I’m still new to Flow, but I have enjoyed working with it thus far, and hope to continue using it in future projects. If you want to check it out for yourself I’ve included some resources that I found helpful along the way:
- Official Flow Docs
- flow-typed —A central repository for Flow library definitions
- graphql & redux-form — These projects source files are a great resource as they both use Flow.
- Authoring and publishing JavaScript modules with Flow
- Online Flow editor
