Skip to content

Instantly share code, notes, and snippets.

@matthargett
Created November 19, 2018 21:00
Show Gist options
  • Save matthargett/07804ef5dcaa7854bce76d53724bd57b to your computer and use it in GitHub Desktop.
Save matthargett/07804ef5dcaa7854bce76d53724bd57b to your computer and use it in GitHub Desktop.
TypeScript versus flowtype

First, let's note the difference in philosophy: TypeScript aims for fast analysis because you can to compile it down to JS before you can run/test it. flowtype is meant to be an async analysis that can run continuously with changes since the last analysis, or in parallel with your eslint and bundler rules. As such, flowtype's type system and analysis is not quite as concerned with speed or memory usage in service of potentially finding more bugs.

On two occasions I have tried to roll out flow in React Native applications, and on those two occasions we ended up backing out after a few weeks. Some detail: flow doesn't have a public roadmap, and what version you use is dictated by the react/react-native dependency and the annotations in react-native itself. flowtype also has some hard-coded aspects to help the analysis for React, so major updates to React itself sometimes also require updating flowtype to match. React Native upgrades then get gated based on your dependent libraries (or flow-typed) being updated as well: flow-typed/flow-typed#1857 (comment)

This is a cheat only Facebook can do, the rest of us have to duplicate our definitions and there's currently no way for one definition to depend on another. The reason this works at all for anyone is because Facebook has a monorepo in their deployment of flow, so packaging and versioning aren't issues for them: flow-typed/flow-typed#2842

Following both TypeScript and flow over the last two years, and talking with core committers to both, they are very competitive in terms of core type system and analysis features. One finds bugs the other doesn't, and vice versa. Both have the downside of being single-vendor solutions, and neither are managed by independent standards bodies. Neither has full support for variadic generics, which was a key type system feature for C++ and C#. TypeScript appears to be pushing back on this feature due to the compute required (read: build times) in common cases, whereas flowtype is making more progress. These kinds of features are less important for app developers, but more important for library developers.

Microsoft has published a spec for TypeScript under the Open Web Foundation, and has a reasonable history of merging code changes and some spec changes from third parties (50% contributors are external in the last month). So far they have hit all of the release dates for milestones in their roadmap over the last year. Both of their issue trackers and PRs are a mess with many, many open items. That being said, TypeScript has had 346 commits over the last month versus 291 for flowtype. The diversity of committers is roughly the same between them.

Since babel 7 is supposed to enable generation flowtype from TypeScript definitions, I feel that TypeScript is the better and more flexible choice for developer experience and bug-finding. Developers can get near-instant feedback as they type in their IDE without draining battery life or using gigabytes of RAM, and we can do flowtype checks (and minor manual) annotations as-needed to cover the gaps in TypeScript analysis. There are currently blockers with TypeScript, (like babel/babel#8244 (comment) ) but I feel we have a better chance of contributing/funding the changes we need in babel and TypeScript versus flowtype and flow-typed.

I've only really come around to TypeScript being the practical option in the last few months after deep discussion with my colleagues and the community. I hope laying out my reconciliation process helps others, whatever the decision people make are.

@jhampton
Copy link

Thank you for laying out your thoughts, sir. I've had a gut feeling for the last few months (as you know) that TS has longer legs. I also think that, given its compile-first nature, there will be more opportunity for transpilation to other (read: more native) languages for myriad reasons.

Now I just need to redo a few months worth of publicity and work :)

@Bardiamist
Copy link

I using Flow beacuse React native using it internal. If React native switches to TypeScript then the choice will be obvious to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment