Vladan Djeric explained the change in Flow philosophy as following:
To make Flow adoption easier, we’ve made design choices that hamper scalability (for example, relying on global inference […]) and hurt type safety (allowing untyped code and
Today, almost all of Facebook’s codebase JS files have Flow enabled, and over 90% are at the highest level. Strict flow Standard. With this evolution of our codebase, we’ve changed the tradeoffs Flow makes. […]
The high internal adoption of flow types and the rapid growth of our code base also means that we need to focus on scalability.
The Flow team will have a clear focus on improving performance at scale, increasing type security, and improving the IDE experience.
Flows Types first The architecture, introduced a year ago, seeks to dramatically improve performance on large code bases. Flow’s Types First allows code dependency checking not to be checked, which in turn speeds up the incremental type checking that takes place when a source file changes. The Flow team gives the example of a file
f with the following code dependencies:
In classic type checking mode, dependencies must be checked as a whole:
With Flow’s template annotations, the type checker does less work and does it faster:
Types-First is currently the only mode in Flow since the start of this year. In practical terms, this means that developers using Flow should fully annotate module boundaries rather than relying on Flow’s type inference. The gains in exchange for the extra effort are substantial:
Avg: 9.10s -> 1.37s (-84.957%)
p50: 1.95 s -> 0.90 s (-53.763%)
p75: 7.85 s -> 1.95 s (-75.143%)
p90: 22.5 s -> 2.83 s (-87.456%)
p95: 42.8 s -> 3.42 s (-92.006%)
p99: 107s -> 5.63s (-94.730%)
Djeric said the Flow team will introduce new language features and new syntax that go beyond type annotations to meet the needs of internal Facebook users. While Flow remains open source, Flow will only accept pull requests that align with the priorities of the Flow team, including improving Flow’s documentation and library definitions. Pull requests and GitHub issues that do not match Flow’s priorities can be closed.
We realize this change may make Flow less suitable for use in some projects, but if you use Flow and align with our focus areas of type security, scalability for very large codebases, and Improved IDE experience, Flow can still be the right choice for your project.