Flow Type Checker is no longer just JavaScript with types, Facebook’s needs centers


Vladan Djeric, engineering manager supporting the Flow team at Facebook, recently announced that the Flow type checker will go beyond just being JavaScript with types and introduce new features based on the needs of internal users of Facebook. In particular, Flow strives to provide fast and robust type checking on large and complex code bases, such as Facebook. The view of Flow is in contrast to that of TypeScript – JavaScript with syntax for types.

Vladan Djeric explained the change in philosophy of Flow as follows:

Internally, we have tens of thousands of developers writing JavaScript, including one project with tens of millions of lines of code. The team’s priority is the needs of our internal Facebook customers. […]
To make Flow adoption easier, we’ve made design choices that hinder scalability (for example, relying on global inference […]) and harm type security (allowing untyped code and any types).
Today, almost all of Facebook’s codebase JS files have Flow enabled, and over 90% meet the highest Flow Strict 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.

Flow’s Types First 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:

(Source: Types-First: A new scalable architecture for the flow)

In classic type checking mode, dependencies must be checked as a whole:

(Source: Types-First: A new scalable architecture for the flow)

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. This effectively 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:

Facebook has tens of millions of lines of JavaScript code. Overall, we have seen rechecking accelerations of ~ 6x in the p[ercentile]90 and ~ 2x in the p[ercentile]99 when we deployed types-first in our codebase. The type of reverification that has seen the greatest improvement with types-first is unchecked dependencies recheck. This is the check that occurs when a user opens a file whose dependencies have not been verified. There we saw the following improvement:

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: 107 s -> 5.63 s (-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 Flow team priorities, including improving Flow’s documentation and library definitions. Pull requests and GitHub issues that do not match Flow’s priorities can be closed.

Djeric concluded:

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 a Improved IDE experience, Flow can still be the right choice for your project.

Source link


About Author

Leave A Reply