Is TypeScript worth it? Making the case to your team

“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.

Folks,

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 makes no pretense of being a new language. It’s more retrofit than replacement, and it goes to considerable lengths—sometimes to its detriment—to play nicely with familiar JavaScript idioms.

All told, we’ll likely spend more time addressing previously-implicit assumptions we’ve imposed on ourselves than in learning the semantics of the language.

Will TypeScript become obsolete tomorrow?

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 a future shift towards purpose-built languages like Reason or Dart won’t diminish our investment in TypeScript. Remember: we aren’t chasing diminishing returns from whatever’s 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 make a program easier for both people and machines 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. In many cases, type annotations may replace the documentation we’re maintaining by hand. They’ll make it easier for our team to collaborate and reason about each other’s work—and improve autocompletion and refactoring support 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.

Warmly,