I can’t imagine working on another JavaScript project without TypeScript, and I haven’t heard much talk of teams adopting TypeScript and regretting it. (For every hour you spend on TypeScript overhead, you probably save five hours of tracking down runtime errors.)
Nevertheless, I do think there are some conditions that could make TypeScript less valuable for a particular project or team. In this article, I’m going to talk about the things you ought to consider when weighing whether or not to add TypeScript to your project.
1. Greenfield vs. Brownfield
In terms of greenfield projects, TypeScript is a no-brainer. Whatever pain you might feel in writing TypeScript instead of JavaScript will be worth it.
TypeScript brings really effective static analysis to JavaScript projects. Static analysis grabs a whole category of run-time errors and makes them compile-time (or red squiggly-line-time) errors, so you don’t have to run your app to find out it doesn’t work.
To give you an idea of how much time this has saved me on my current project, I’ll tell you this: I haven’t had to invest time in configuring a watch because I just don’t find myself chasing down [object Object] errors or undefined is not a function run-time errors enough to merit the investment.
If you’re working on a brownfield project, the decision becomes a little tougher. TypeScript would be helpful for new code that you’re writing, and adding it incrementally might cause a headache if you’re digging into code that isn’t typed.
Consider that your module relies on an object that another module produces with lots of properties and nested objects. Step one would be to type that object, but then you have to decide to either cast what that module gives you or type all of the functions and references in the other module. That module may have dependencies in your codebase, so then you’re faced with making the same decision again. And while casts are convenient, they can lie, too, which leads to types in your codebase that you can’t trust, which circumscribes the whole reason TypeScript is great.
2. Uniform, Idiomatic Adoption
Although TypeScript does a very good job of emulating a strong typing system like you’d get in Java, the user is the weakest link since there are always opportunities to add the wrong type or no type.
Since TypeScript is a superset of JavaScript, it’s easy to write TypeScript that looks a lot like JavaScript and doesn’t provide much of the value that TypeScript is supposed to bring. Also, a big chunk of the value of using TypeScript comes from using it consistently throughout your codebase. If you’re working on a team, it’s important that everyone buys in to writing idiomatic TypeScript, or else you could end up with a lot of functions returning any, which would be a really frustrating experience: not knowing when to trust the TypeScript compiler.
I’ve found it really helpful to have a TS expert who takes to heart our teach and learn value during code review. Another helpful mechanism is to invest some time in configuring TSLint as well as a picking out helpful tsconfig compiler options like noImplicitAny.
Bottom line: TypeScript isn’t worth the price of admission if you don’t know when you can count on TypeScript’s compiler to yell at you about errors that you or someone from your team hid from it.
3. Toolchain Fit
To keep TypeScript from becoming a PITA in the management of your project, you need to make sure of two things:
- You have an IDE that has TypeScript support. I’ve used both IntelliJ and Visual Studio Code and can attest to both providing excellent support. IntelliJ’s is so good that sometimes I swear I’m on a Java project instead of a full-stack JavaScript project.
- Your toolchain for building/packaging/running/watching your web app is 100% seamless. There’s lots of community support for TypeScript compilation with tools like Grunt, gulp, and webpack, but it can be a little futzy when it comes down to utilizing these tools with advanced TS features like multiple
tsconfigs.
4. Server Language
If you’re writing a Node server, this is basically a no-brainer; you have even more of an incentive to adopt TypeScript. Very likely, a lot of the types you create on the back end will be extremely useful when it’s time to present them on the front end.
Not only that, but seriously, if you’re writing a Node server, there are few places where static analysis is more helpful than in dealing with complex business logic that ought to be captured on the server.
5. Integration with Frameworks and Third-party Libraries
Integration with frameworks is a moot point for 97% of the market share of JavaScript frameworks, but I mention it here because it’s a really obvious question: Will TypeScript play nice with [insert frontend framework of your choice here]? Though I haven’t used TypeScript with all of the frameworks on this page, the sheer volume of framework-specific quick-start guides at your fingertips suggests the answer is yes.
A possible risk occurs if you rely on a library that doesn’t provide good type definitions or hasn’t had someone in the community publish some through Definitely Typed. An example is the Lodash (I love Lodash) chain function.
Though it’s possible to type chain, if you are a heavy user of third-party libraries, you may need to spend some time investigating what kind of TypeScript support is out there or what kind of investment it would be to create (and maintain) type definitions.
And that’s it! I hope you found this discussion of TypeScript helpful. Also, if you, dear reader, know of a type of JavaScript project for which TypeScript would add negative value (and Flow projects don’t count), please tell me about it, because I haven’t been able to think of one.