We all make mistakes in the technical planning process that bubble through to execution. Looking back over the past 10 years or so, these are the two biggest tech & development mistakes that I think I have made and the lessons that I’ve learned from them.
Choosing Flow over TypeScript
We ended up choosing Flow because:
- We had many Babel plugins we needed to use and Babel was not TypeScript-compatible. Switching to TypeScript would mean using
ts-loaderwith Webpack and we would have to rewrite our entire compilation setup and change any Babel plugins into Webpack plugins. This would have been a huge undertaking.
- React was written using Flow and thus was poised to be a better support model.
- TypeScript either did not have a strict-enough mode in it. There were too many examples at the time that would just pass through, despite best intentions by developers to produce strictness.
- TypeScript was slow across large codebases.
- Flow as fast. We were able to get checking across an entire monorepo with about 10,000 Flow-typed files to run in about 20 seconds.
Flow ended up being a mistake because:
- Adoption lagged. While we jumped on Flow, everyone else started jumping to TypeScript.
- The core team at Facebook changed directions multiple times and eventually stated publicly that they didn’t really intend to continue interfacing with the open source community, but would continue publishing releases.
Unfortunately, before we realized that TypeScript was taking over and would have been a better choice, we were somewhere like 75-85% Flow coverage. Interop between Flow and TS is not possible and so another slow migration over to TS would not be possible.
Lesson for type safety
I’m not sure that at the time we could have seen it coming that Flow would essentially be dead for anyone external to Facebook/Meta. Next time something like this comes up, I will try to do more due-diligence in checking with the open source teams in understanding their roadmap as well as watch the community’s traction more closely. I would also try to make sure we have an ejection plan if things go sour with the choice we make.
Using a multi-language monorepo
Lesson for monorepos
My lesson for Monorepos is that they are actually good, but they only scale as long as you’re using a single language and every workspace internally has some connection to the same graph. As soon as you have a workspace or project that doesn’t use any of the same stack, tools, or language, a new repo is likely the best course forward.