The Business Case for TypeScript
Maybe you're on the TypeScript train and you find that question triggering because you've heard it a million times before and your heart screams, Yes! It is worth it! I could never go back! Maybe you feel like you're the last person in the room who hasn't yet drunk the TypeScript koolaid, and, to mix my metaphors, you're wondering if the emperor has any clothes on. So let's do it: let's poke and prod this question and see if there's a business case to be made for TypeScript.
The Business Case For TypeScript
There are a few major reasons you might want to consider using TypeScript: reliability, enjoyability, and hospitality.
3 + "3" === "33" , but of course that's probably not what you really meant in all likelihood. If you're a seasoned developer, you'll rightly respond, "But that's an obvious error! Anyone would spot that, and making me explicitly say that these are supposed to be numbers just wastes time and is just a big annoyance!"
True, and that's why using a trivial example to pitch the value of a production-grade type system is not all that meaningful. It would be helpful, though, to have a tool that would keep you honest when you're pulling in a couple functions from a other modules and piping complex data through them and maybe using a couple functions from packages off of npm, and that's where TypeScript has shined in my experience. Static type systems like TypeScript (or Facebook's Flow) can conservatively catch around 15% of bugs that seasoned developers inadvertently let slip into their code. If your team had an extra 15% time to ship features instead of fixing bugs, that would be nice, wouldn't it?
Catching bugs at compile time or even at development time with editor plugins is a huge win, but there's a big caveat there in my experience. Gradual type systems like these are convenient, but the tradeoff is that they're only as good as you configure them to be combined with how much you cheat the system. Annotating variables as
any , for example, cuts type inference off at the knees and forces the compiler to accept whatever shenanigans you throw at it. There are times and places for using
It is absolutely true that it's pretty irritating to have a type system holding your feet to the fire when you're just trying to sketch out an idea, and so it's pretty tempting to tell the compiler to just shut up and trust you by using
// @ts-ignore ,
foo!.bar , and other tricks. But like good documentation or a robust test suite, a helpful set of types isn't magically created out of thin air overnight—if you don't make it a habitual piece of your development flow, it won't ever happen and you'll keep
any -ing your way out of every jam until the prospect of getting your codebase in shape is functionally impossible.
tl;dr: TypeScript really can quantifiably make your code more reliable if you configure it well and don't cheat the system.
slice that I was needing so I'd have to go look it up. Then I'd forget what the order of arguments was for React's
componentWillReceiveProps() lifecycle method. Then I'd realize I needed a function here that would take an array of users and partition it up according to their age group. Is there a lodash method for that, or am I going to have to write my own?
When I got into TypeScript and started using VS Code, I quickly realized how amazing a productivity tool the TypeScript Language Server is. Regardless of whether TypeScript catches bugs or not, I almost never have to go to look up docs anymore. With autocompleted methods and imports and variable references, I can kind of just type what I'm thinking and see if I have something at hand that solves my problem. If I can't remember what a function does, there is an inline markdown-formatted description for me right there in the autocomplete menu. It shows me the name of the argument I'm currently trying to type in. Sometimes I have to work with a poorly-documented library, but since I have type information I can figure out what I need to do without having to go source diving on GitHub. It's not that I never have to go look at docs anymore, but it's much easier to stay in the flow and get my feature done quickly.
tl;dr: TypeScript can be a really enjoyable development experience that helps keep you in the flow of programming instead of having to alt-tab around various docs.
On another occasion, I had to submit a PR to a different repo that was written in a Go, a language I do not know. It's a statically-typed language, though, so I could pretty easily determine that this needed to be a float and that needed to be an int and the other thing needed to be a string. Again, I don't even know the language, but the code was compiling and tests were passing within a couple hours on a ticket that was supposed to last me a few days.
I want to suggest that hospitality is another angle with which to examine the business case for TypeScript. Just like documentation and tests can help newcomers help themselves, so too can static types be a sort of living documentation about what the code does and how to use it and extend it. Sometimes I can get annoyed that I have to expressly specify the shape of my data when dang it, I know what I'm dealing with here just get out of my way and let me do my work, but the reality is that it is a given that someone at some point in the future is going to have to know about the shape of your data and what its rules are, and they will not already know what they're dealing with. Writing type information is a way to pay it forward to the next developer.
tl;dr: TypeScript can make your codebase more hospitable to contributions from newcomers.
The Business Case Against TypeScript
This will probably be odd, but now I'm going to give you a few reasons and scenarios in which I would actually recommend you do not adopt TypeScript.
It's the new hotness
yarn create react-app my-app --template typescript . But for goodness' sake, do not start porting over your production app to TypeScript when you remain unconvinced. There will almost certainly be a negative ROI for you.
You want it, but nobody else does
.jsconfig file and
// @ts-check comments you can pay it forward to future developers by documenting type information and VS Code can even use JSDoc annotations to help you out a little. It's not the same as having a TypeScript codebase, but your coworkers can't really complain too much and it's at least something.
TypeScript has some of the most innovative, interesting type features of any production-grade language right now, and it has the utilities to encode your business domain quite nicely at a type level. I use features like discriminated unions, conditional types, and mapped types quite regularly to be able to go beyond guarding against adding
3 + "3" and to fail my build if a business rule is broken or to make sure I've handled all possible cases instead of just the happy path.