Making the case for TypeScript: a letter for managers

“But we’re still not using TypeScript,” says the friend across the table. He’s working for a progressive tech company, the sort of place where no-one’s ever too surprised to see Haskell or Julia oozing out from the darker corners of the tech stack. It’s surprising that TypeScript isn’t, but not very. “Our team’s all about it, but our manager isn’t,” he continues.

Heard that one before?

Trendspotting aside, JavaScript’s adherents can be a surprisingly loyal bunch. All that time spent struggling against build tooling and reference errors adds up to a bit of Stockholm Syndrome, I guess, even before a manager’s very rational concerns about keeping productivity up and hiring out of a new-tech tar pit.

Choose boring technology,” the saying goes, and more often than not it’s right. Unless fixing bugs factors into your marketing plans (and maybe not even then), chances are that unproven technology will cost more than it returns.

But every once in a while the hype cycle spits out a new technology that meaningfully improves on the sins gone before. Word gets out. People catch on. And the next thing you know, that technology’s boring.

Guess what?

TypeScript is boring. And if you’re managing or working on a more-than-one-person team building a non-trivial JavaScript application, it’s time to give it a long, hard look.

To make it easy, let’s consider some of the legitimate concerns about TypeScript and why, on closer inspection, they may not be so concerning after all. And to make it really easy, it’s all packaged up in a ready-made letter for you to share with your manager, your team, or the developer across the way at the pub.


We’re all rightly concerned about the cost and distraction of new technology.

But along with the potential risks, we also have to consider the upside. If a new technology promises a compelling advantage over whatever we’re using today, it’s worth at least hearing it out.

With that, consider TypeScript–a strict superset of JavaScript that brings static typing to the language we know and love. In principle, it’s a drop-in replacement. In practice, we’ll get logic that’s easier to understand and maintain, increased confidence around our releases, and likely even an edge in future hiring.

First, though, let’s dispel some of those concerns.

Is TypeScript hard to learn?

TypeScript is a superset of JavaScript, not a new language. Its (optional) type system goes to considerable lengths—sometimes to its detriment—to look and feel like idiomatic JavaScript.

All told, we’ll likely spend more time explaining previously-implicit assumptions in our own logic than in learning the semantics of the type system itself.

Will TypeScript become obsolete tomorrow?

In a word, Microsoft. But with nearly 400 contributors and 50,000 stargazers on Github, TypeScript clearly enjoys significant community momentum as well. It won’t go away soon.

Even serious future traction behind something like Reason or Dart won’t diminish our investment in TypeScript. Remember: we aren’t chasing diminishing returns from the latest and greatest—we’re just chasing a significant advantage over the technology we use today.

Do developers like TypeScript?

Every manager loses sleep over technical decisions, and in the ultra-competitive market for development talent, it’s always prudent to consider the impact on team morale and future hiring. In the 2018 State of JavaScript report, however, 80% of JavaScript developers surveyed would like to learn TypeScript or would like to use it again. Given TypeScript’s popularity among developers, adopting it may actually widen our recruiting appeal.

Do static types slow down development?

The point of static typing is to constrain variables in ways that make their behavior easier to understand. It isn’t to spend extra time dreaming up type definitions or annotating existing logic—the less of that, the better. TypeScript’s compiler is in any event quite capable of inferring many of the well-intentioned-but-redundant details we might try to provide, and goes to lengths to reduce boilerplate added by the type system.

The compiler isn’t our only audience, either. The time we do invest annotating code will also payoff through evergreen, compiler-enforced documentation—making it easier for our team to collaborate and reason about each other’s work—and via much-improved autocompletion and refactoring within our IDEs. Plus, we’ll be able to save writing unit tests just to see if things run. TypeScript won’t verify our business logic, but it can at least ensure it falls within the ordinary constraints.

It still takes time to add types, yes, but we can consider it an upfront payment against “learnings” downstream. By forcing us to consider our design (and grapple with inconsistencies) at compile time, TypeScript can preempt issues that we’d otherwise only discover in production.

Changes to our technology stack are significant investments. Still, it’s hard to overstate the value we’d gain from lower defect rates, upfront design, and better collaboration as a team.

Let’s give TypeScript a long hard look. We’ll be glad we did.


<Your Name Here>

Hey, it's RJ—thanks for reading! If you enjoyed this post, would you be willing to share it on Twitter, Facebook, or LinkedIn?