Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News TypeScript, Seeing Past the Hype - Matthew Gerstman at ReactiveConf 2019

TypeScript, Seeing Past the Hype - Matthew Gerstman at ReactiveConf 2019

Leia em Português


Matthew Gerstman, senior software engineer at Dropbox, recently presented at ReactiveConf 2019 in Prague the lessons learnt by Dropbox after they migrated to TypeScript four years ago. Gerstman described the good, the bad and the ugly parts of TypeScript, and how TypeScript helped Dropbox to tackle programming at scale.

Gertsman started with giving the audience a practical definition of types, as an attribute of data that tells the computer how the programmer intends to use it. Basic preexisting TypeScript types (like Boolean, String or null) can be combined to form other types, with the any type being an escape hatch encompassing the type of every possible value. In a standard TypeScript codebase, programmers typically annotate code with the relevant type information. Through type inference, TypeScript is then able to detect occurences of type mismatch and inform the user of incoherences at compile time.

Gerstman illustrated with live examples how the IDE leverages TypeScript to support type error reporting while editing code. With proper typing, the IDE understands the shape of the props expected by a React component and is able to complain instantly about missing props when calling that component, in all relevant call sites. IDE may also leverage third-party libraries’ TypeScript definitions to enable automatic completion for developers.

The increased developer convenience comes at a price. Types can be complex enough to be difficult to grasp, specially for developers who are just starting to use TypeScript. As a matter of fact, the filter method from the popular lodash utility library has 14 different type definitions, most of which are derived from other (possibly derived) types with also a significant number of overloaded type definitions. Gerstman additionally explained that testing requires very well mocked data or lots of anys. Furthermore, because advanced JavaScript translates to advanced TypeScript, some functional patterns like higher-order functions , according to Gerstman, are really hard to type: developers need to know about generics, intersection types, and discriminated unions. It may even be that some functions may not be typed accurately enough to guarantee type safety.

This results in Gerstman warning developers:

TypeScript is going to get in your way for the first few months.

Continuing on the list of potential issues with TypeScript, Gerstman mentioned that TypeScript is not sound, as it may allow some operations whose safety cannot be guaranteed at compile time. Some of this is by design, to strike a balance between correctness and productivity. Another part comes from the fact that a typical codebase may import foreign codebases, which may be inadequately typed (for instance with substantial use of any). Sebastian McKenzie, creator of the Babel JavaScript compiler and the Yarn package manager, testified on Twitter:

Local variable refinements are unsafe in TS and Flow. Both are bad, TS is the worst. Seems obvious in hindsight but neither handle local refinement invalidation correctly. I’m not speaking abstractly, this has caused bugs in my code before.

As part of the list of abstractions which are difficult to thoroughly type with TypeScript and that are used commonly by front-end developers, Gerstman quoted React Context, React Redux (implemented with React Context), Redux Thunk or dispatch. In such cases, developers will often have to help the TypeScript type system to infer the correct types by inserting type annotations.

In spite of the aforementioned issues, Gerstman nevertheless contended:

All of this is worth it.

TypeScript eliminates classes of bugs, among which the undefined is not an object and variable is not a function classes. Gerstman explained that at Dropbox scale, with hundreds of engineers across four time zones working on the same codebase, hundreds of features, and millions of lines of code, TypeScript provided hard-to-replicate benefits, and became a core part of Dropbox front-end workflow. Gerstman mentioned:

At our scale, I don’t know how we would upgrade libraries without TypeScript.

Gerstman then provided practical examples of TypeScript benefits at Dropbox. In Dropbox’s experience, TypeScript catches the vast majority of breakage when upgrading a library. TypeScript allows Dropbox to place constraint on engineers, such as preventing usage of some methods in a library. Dropbox as a matter of fact temporarily prevented usage of Hooks, or restricted lodash usage.

Gerstman added that while TypeScript does not provide free documentation, nor free tests, it does provide contract validation across the stack, from the back-end all the way to the component library. Developers may use for APIs GraphQL, Swagger, or Dropbox’s Stone and autogenerate backend types in TypeScript. Changes in APIs thus are immediately propagated to the front-end, and any possible breakage is detected ahead of time. Conversely, when the front-end team updates the component library, TypeScript types also allow to detect the impacted piece of codes and correct immediately possible misalignment occurring in other places.

Gertsman warned however that with TypeScript developers still need to write tests, perform code reviews, and think about architecture. Still, TypeScript allows developers to forget about other parts of the codebase which are impacted by a change, and that is according to Gertsman a key advantage for maintainability. As he explained:

The metric for success in a codebase is how few things you need to keep in your head at a time.

Gertsman limited the cost of TypeScript to the learning of it, which may take time and feel painful in the beginning, and concluded by arguing that that cost is not so expensive versus the benefits derived from an easier refactoring and better code maintainability, especially in large codebases.

ReactiveConf is a yearly conference targeted at developers with talks addressing the latest technologies and trends in software development. ReactiveConf 2019 took place Oct. 30 - Nov. 1, 2019, and is the fifth installment of the event.

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.