What the Flow team has been up to

Last updated 3 years ago by Avik Chaudhuri


Hello! (And sorry for the radio silence.)

A lot of our open-source users are rightfully observing that the Flow team has effectively stopped paying attention to an ever-growing list of issues and PRs on GitHub. And while there has been a lot of activity in terms of GitHub commits during this time, there has been little to no communication about our roadmap.

We understand that this state of affairs is deeply concerning to our open-source users, to say the least. We are sorry. We are thankful to those who have been constructive with their criticism over the past several months. This post is a baby step towards fixing this problem.

The simple and honest explanation is that we were too heads-down on addressing Facebook-internal challenges, and felt too resource-constrained to do much else. It didn’t have to be this way, and we could have done better.


In 2018 we created an internal roadmap to address the biggest challenges for our internal users. We were seeing unprecedented growth in the number of JavaScript files covered by Flow, and we were not keeping up in terms of both performance and reliability. Developers were waiting for multiple seconds, if not minutes, for the codebase to be rechecked after making edits in their code. And they were complaining that we were still not preventing enough new bugs landing in the codebase and breaking their code. They wanted:

  • Responsive IDE commands to drive frictionless code navigation, understanding, and development, irrespective of growth of codebase. And fast rechecks to make changes quickly, iteratively, and confidently, irrespective of growth of the codebase.
  • Reliable types that accurately describe run-time invariants and help reduce crashes in production, justifying investments in improving code quality through Flow coverage. And reliable code intelligence results exposed to IDEs and other tools.

Thus we identified the following focus areas spanning a couple of years:

  1. Performance: Make Flow scale as O(size of edits) rather than O(size of codebase), which necessarily involves projects aiming for big-O improvements.
  2. Reliability: Make Flow type analysis trustworthy with respect to run-time semantics, not only for product safety and developer efficiency but also to explore opportunities for runtime optimizations.
  3. Language tooling: Make Flow the basis for unified JavaScript tooling to enable language evolution for performance and reliability.

Our goals were very aggressive: we needed to cover a lot of ground in terms of scalability and trustworthiness, and we wanted to front-load the hardest parts first, which meant focusing on big-O performance improvements over the past six months and moving on to fundamental reliability improvements over the next six months.

Through this time, we shifted around some work on our long-term goals to respond to shorter-term needs, in particular on reliability. By the end of 2018 we are overall further along than expected on our long-term goals, having hit or close to hitting most of our planned milestones on performance as well as delivering significant additional results on reliability that were planned for 2019, while making solid progress on language tooling to unblock this work and improve our chances of success as we proceed.


Read full Article