We are planning to standardize our JavaScript stack on TypeScript, where previously we tried Flow on several projects. You can scroll to bottom to see my "hot take" on TypeScript vs Flow.
This post is mostly a collection of references to posts where others have made strong cases for using static types and TypeScript. I've tried my best to include a TL;DR with some comments.
TL;DR:
- A large number of errors can be caught early in a statically typed program.
- Types guide development, usually leaving with less for the developer to specify.
- Refactorings can be completed more confidently because a large number of a errors introduced by refactoring are type errors.
- Static types ease the mental burden of development.
- Types are documentation.
- Static typing takes upfront investment.
- Static typing is a constraint on your program.
- Generic programming is more difficult to do in a statically typed language because it requires more setup.
- You always have to chose what information you want to encode in your types and this can be problematic when you’re unsure about what to encode.
- The author started with C++ and Java, learned Python and became interested in dynamic typing. Only after many years he realized the trade offs made in static typing. He argues that Java has bad “user experience” around typing which is what turned him off of it in the first place.
TL;DR:
- "...statically-typed languages perform type checking at compile time, while dynamically-typed languages perform type checking at runtime."
- "Type-checking verifies and enforces that the type of a construct (constant, boolean, number, variable, array, object) matches an invariant that you’ve specified. You might, for example, specify that “this function always returns a string.” When the program runs, you can safely assume that it will return a string."
Gabe commentary:
“When the program runs, you can safely assume that it will return a string.” is not strictly true for TypeScript or Flow because the type-checker can be cheated.
TL;DR:
- "Advantage #1: You can detects bugs and errors early"
- "Advantage #2: You get living documentation"
- "Advantage #3: It reduces convoluted error handling"
- "Advantage #4: You can refactor with greater confidence"
- "Advantage #5: It separates data from behavior"
- "Advantage #6: It eliminates an entire category of bugs"
- "Advantage #7: It reduces the number of unit tests"
- "Advantage #8: It provides a domain modeling tool"
- "Disadvantage #1: Static types require investment upfront to learn"
- "Disadvantage #2: Verbosity can bog you down"
- "Disadvantage #3: Types take time to master"
- "Disadvantage #4: Static types can hold up rapid development"
Gabe commentary:
The disadvantages offered here are poor and contradict some of the advantages. They all center around one theme: You have to learn how static typing works. Once you are comfortable with static typing and the various compiler error messages, not having types feels like a huge disadvantage. Types will make you faster as the project grows.
- “Types are tests for the structure of your data”
- “Types like us prove something about our code before we execute tests”
- Type annotations reduce the cognitive overhead of figuring out the type of variables in your code, also through editor integration
- Flow has a lot of inference features, so only the exports of a module need to be typed most of the time
Gabe commentary:
Very good talk that repeatedly points out how types are tests you write ahead of time.
TL;DR:
- A review of an academic paper by the same name
- The authors estimated that ~15% of bugs in the software tested could have been caught with static typing
TL;DR:
- Lists the major differences between TS and Flow (slightly outdated from what I can tell)
TL;DR:
- Reddit redesigned their website and they chose TypeScript. Their decision was based on several factors:
- Must have types.
- Must have good tooling already.
- Powers major production apps.
- Our devs should be able to onboard fairly quickly.
- Should work on both the client and the server.
- Good library support.
- After considering all of these factors, the only two options were TypeScript and Flow.
- The biggest reason for choosing TypeScript was because of the “social proof”. It is more popular: library support is better; tooling is better; and a number of large projects are written using TypeScript.
TL;DR:
- TypeScript is much more popular than Flow and that counts for a lot
- TypeScript does LESS to infer types and that’s better because you’re forced to be more explicit
TL;DR:
- TypeScript has better error messages
- TypeScript catches more errors (Gabe: not sure that I believe this?)
TL;DR:
- Main argument for using Flow is how it does type inference. I agree that it does a much better job than TS at this.
- A lot of fanboys rushing in to argue that TS is, in fact, superior to Flow.
- A few people saying that you shouldn’t use types at all (lol).
One of the nice things about TS is that it removes the need for Babel. The TS team is creating releases on a six week cycle where new JS language features are added to TS as soon as the spec is stable. Upgrading the compiler is just a version bump.
Out-of-the-box support for TypeScript. Honestly the best JS development experience I've had. Sometimes turns my computer into a hot plate, though.
This is repo with over 4500 community-maintained TS definitions. If something has over 100 stars on Github, it probably has type definitions here.
For what it's worth, I've using TypeScript for everything over the last half-year. Prior to that, I used Flow for a year-and-a-half as part of the Convertibuddies. Here are the main differences I've noticed.
- My experience with Flow on Convertibuddies showed me that having static types can save you a lot of pain. Refactoring is a breeze. Small bugs are caught almost instantly. When I helped out with the Marketer-vs-Machine project, I almost had a heart attack because I was creating annoying little bugs that would have been caught otherwise. I will never go back to dynamic typing if I can help it.
- Flow is much better at type inference. Especially for private functions inside of a module this is really nice.
You must only type functions and classes and are being exported from the module. TypeScript on the other hand
assumes that your arguments are typed
anyunless you explicitly correct this. This is considered anti-pattern and there is a compiler setting that prevents you from not typing inputs. However, unlike Java, TypeScript is able to infer the types of variable declarations. - If you want to be able to do anything useful with your types in Flow, you have to know about the built-in "private" types which is very annoying; especially because they are not in the documentation.
- Facebook routinely breaks the Flowtype API. I can’t just upgrade and get the new features.
It leads to a reluctance to upgrade. Last I checked
ub-emb-universalscriptis 14 versions behind the latest. - Contrast with TypeScript which is on a consistent 6 week minor release cycle. They rarely release breaking changes in minor releases.
- The “community” support for TypeScript is noticeably better.
- Almost all planned changes are done as issues on Github.
- Many more type definitions for third party libraries through DefinitelyTyped
- TypeScript + VSCode is a fantastic developer experience. The intellisense is better than anything I’ve used.
- Just like with Flow, TypeScript allows you to use very strict rules around what is allowed through TSLint.
For clarity, we're standardizing on Typescript for new JS projects (front-end or in Lambda functions) or large rewrites (e.g. builder 2.0). We don't have a plan to migrate existing projects such as Convertables, which uses Flow. That's something we can explore if we think there are benefits to migrating.