Summary: Flow prioritizes the Facebook codebase’s need for more type safety and fast performance on very large codebases. Flow’s over-arching phil

Clarity on Flow’s Direction and Open Source Engagement

submited by
Style Pass
2021-05-26 00:30:04

Summary: Flow prioritizes the Facebook codebase’s need for more type safety and fast performance on very large codebases. Flow’s over-arching philosophy is evolving beyond just “JavaScript with types” and we will add new language features including new syntax that goes beyond type annotations to address internal users’ evolving needs. We are also making changes to how we engage with open source. Read on for more details.

This work aligns with our three focus areas: improving performance at scale, increasing type-safety, and enhancing the IDE experience. These will continue to be our focus areas in the future.

Flow is almost exclusively developed by a 10 person team within Facebook, and our primary customers are Facebook engineers who use Flow. Internally, we have tens of thousands of developers who write JavaScript, including one project with tens of millions of lines of code. The team’s priority is the needs of our internal Facebook customers. When Flow started, Facebook’s internal JS codebase had no types. The top priority was to enable types to be added to the codebase in a gradual and easy way. To ease adoption of Flow, we made design choices that hurt scalability (e.g. relying on global inference which does not require type annotations at module boundaries) and hurt type-safety (allowing untyped code and any types). Today, almost every JS file in Facebook’s codebase has Flow enabled, and over 90% are at the higher Flow Strict standard. With this evolution of our codebase, we have changed the trade-offs Flow makes. A high degree of internal Flow adoption means we can now focus on increasing type-safety and predictability. Doing so means limiting the kinds of programs Flow allows, including restricting otherwise valid JS patterns to increase the safety and predictability of our overall system. High internal adoption of Flow types and rapid growth of our codebase also means that we have to emphasize scalability. These choices might make Flow more intrusive (for example, asking for more type annotations) to use on external projects that don’t have the same needs, like small projects or projects that interact with untyped code. Large, complicated codebases not only require good performance, but increased type-safety and developer ergonomics. While so far Flow has de-facto been just “JavaScript with types”, this is not a guiding principle. In the next year, we will introduce new language features, including new syntax that goes beyond type annotations, to address our users’ evolving requirements. Stay tuned for more details.

The fast growth of Facebook’s internal JS codebase and the great demand from Facebook developers mean that sadly we do not have resources to work on features requested only by external developers. We also handle a very large amount of internal support requests, so we also do not have the resources to respond to all external Github issues. This lack of resources manifests as regrettably long response times to GitHub issues and PRs. Going forward, Flow is staying open source and we will be happy to review pull requests that improve library definitions and website documentation, but we may not be able to accept PRs for Flow itself if the PRs don’t align with our priorities. The complexity of Flow’s codebase makes it difficult to contribute to Flow itself, and our company-internal build systems, performance tests and integration tests make it very time consuming to review and integrate such pull requests, so we may close PRs that don’t align with our priorities. Similarly, we will close GitHub issues when we know we will not be able to provide timely support. 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-safety, scalability for very large codebases, and an enhanced IDE experience, Flow may still be the right choice for your project. Finally, we want to give a shout-out to the hardworking maintainers of flow-typed who maintain community type definitions for third-party libraries! The flow-typed community-led model has proven itself very effective, so we will investigate moving more of our builtin type definitions (DOM, Node, React, etc) to flow-typed to enable the open-source community to depend less on Flow’s release cycle and Flow team’s review & approval process.

Leave a Comment