“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?
“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.
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.
First, though, let’s dispel some of those concerns.
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.
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.
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.
<Your Name Here>