Refactoring for Fun and Profit: From TypeScript to Flow
Initially, I’ve built this website with TypeScript. During development, I neglected to follow the TDD methodology. Didn’t do a thorough research of the eco-system. Had no solid goal of what should be the end-product. And in the end, had to rewrite everything from TypeScript in Flow. Why? There are several points that helped me decide on this rather expensive process of refactoring the whole codebase.
- Type Definitions - DefinitelyTyped is incredible. How smoothly it integrates with VSCode. How fast and easy it is to use. There are thousands of types for all sorts of packages ready to be used. Flow, on the other hand, offers a more modest option: flow-typed. Although it is well maintained, fewer people use flow and thus contribute less by creating type definitions and supporting existing ones. The issue for me was the nature of TypeScript itself, and how an error in an existing type definition propagates towards end-user. After updating dependencies I’ve had functioning code blow up on me with type errors due to minor changes in type definitions or even TypeScript itself, which started to drive me crazy. On the other hand Flow by its nature is more of an add-on than a language, with its opt-in behavior. It is much easier to circumvent such annoying behavior. And last but not least, Flow type definitions for React are created, used and supported for Facebook.
In the end, I’m glad that I’ve had to experience a complete refactoring process. This allowed me to learn a lot more about TypeScript and Flow, their eco-systems and what pro and cons each language have.
And by no means, one language is better than other. I love both TypeScript and Flow, and cannot imagine starting a new project without using one or the other. Tools and requirements can differ and to choose proper one’s matter a lot. But static type-checking is a must.