“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 explaining previously-implicit assumptions in our own logic than in learning the semantics of the type system itself.
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.
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>