by Jason Dreyzehner
It’s time to give TypeScript another chance
And if you haven’t been watching closely, you may have missed TypeScript’s amazing progress over the past year (and even the past few months).
If you’re still thinking “TypeScript is kinda like CoffeeScript, right?”—this article is for you.
There are dozens of great resources and articles on the benefits of using TypeScript. I hope that after reading this, you’ll take another look.
“To be attractive to hackers, a language must be good for writing the kinds of programs they want to write. And that means, perhaps surprisingly, that it has to be good for writing throwaway programs.” — Paul Graham, Being Popular
Here are some insights that might help to ease those fears.
TypeScript is like a highly-advanced linter, able to check documentation and warn when code is not being used as intended.
It provides immediate feedback and a better development experience for all future users of your code. This is also a good test for new projects—if your project is worth linting to enforce code style conventions, your project is probably long-lasting enough to benefit from TypeScript.
TypeScript eliminates runtime overhead
Another common misconception is that TypeScript’s type checking somehow persists into the runtime environment, adding complexity and overhead.
In fact, TypeScript is a good way to avoid runtime type checking overhead.
TypeScript’s type-hints give us all the benefits of types, and then they disappear.
These libraries don’t intend to do this at the outset, but part of providing a good development experience is ensuring developers see clear and actionable errors when they’ve made a mistake.
In pursuit of this goal, many libraries extensively check the types of parameters passed to methods at runtime, throwing errors meant only for the eyes of the developer implementing the method.
This is most certainly the worst of both worlds. These cascades of runtime type checks add significant code bloat, make code less readable, and increase the difficulty of maintaining 100% unit test coverage.
Across large codebases, these runtime tests really add up. After a bit of refactoring, many largest codebases end up with whole type systems.
Without using Typescript, not only do you lose out on development-time type checking—you often shift it into runtime. (I hope you have full test coverage.)
When you use TypeScript, you provide your users with an even better development experience, reduce runtime type checking to only cases where it’s needed (sanitizing end-user input, for example), and make your code easier to fully unit test.
TypeScript has come a long way
Since TypeScript tracks ECMAScript, using TypeScript doesn’t lock your project to a new language. A lot of people still don’t realize this, so it’s not uncommon to hear sentiments like:
“It’s hard to maintain a TypeScript project.”
Which, to me, sounds like:
“It’s hard to maintain a project with linting.”
If your project somehow stops benefitting from TypeScript, you can run your project through the compiler (one last time) to remove all types from your codebase.
TypeScript has improved a lot recently. If you heard about TypeScript years ago, but haven’t really followed it since then, it’s worth another look.
When to use TypeScript
A short technical discussion of exactly why the Angular team chose TypeScript to build Angular 2.
A summary of why Typescript is a good idea for JS libraries, from the creator of Cycle.js and contributor to RxJS.
A good summary of the benefits of using TypeScript. (TypeScript Deep Dive is a great general reference.)
Learn about TypeScript
A short tutorial maintained by the TypeScript team.
A short wiki outlining the TypeScript team’s general design principles.
I wrote this with the hope of changing minds. If you have any ideas for how I could improve this article, please let me know.
Please ♡ and share this post if you found it interesting. Thanks for reading!