Is TypeScript worth it?

I just read Chris Coyier’s You Like It Because You Know It, in which he shares some thoughts about TypeScript and wonders whether it’s worth it.

I’m in a similar position: I’ve been writing TypeScript professionally for over six months, and used it in hobby projects on and off for a year or two. Unlike Chris, I’m definitely on team TypeScript now (but I won’t be obnoxious about it, I promise).

The wrong type of bug

I have lingering doubts about how many bugs are actually about types. Of all the JavaScript bugs I’ve fixed in my years, it honestly doesn’t feel like that many were about wrongly typed data being flung around. Some days it feels like a wild hoax that an entire language was invented around solving these not particularly common bugs.

It took me years to thoroughly understand the dangers of JavaScript’s dynamic typing and learning how to mitigate potential bugs. I think, like myself, many JavaScript programmers learned to use the strict equality operator (===) and obsessively validate values.

With TypeScript, we still do. It only helps us avoid bugs by forcing us to be explicit about types, or rather type annotations. TypeScript only transpiles code and detects mismatching annotations. It’s a facade, smoke and mirrors, a JSDoc on steroids.

const n = 4.2 as any as string;
console.log(n.substring(0, 1));

The above code will transpile without a problem. When executed, however, JavaScript will throw a type-related error. Because we have to jump syntactical hoops to use a number as a string, we become aware of the issue before it happens — TypeScript prevents type bugs through us. Instead of relying on our own discipline to mangle data responsively, we can shift some of that responsibility to TypeScript.

Data you can trust

Now that we’ve established TypeScript doesn’t actually do much other than make types visible, let’s explore more indirect effects.

As I learned to mitigate type errors in JavaScript, I started by validating parameters for every function. This adds a lot of noise and repetition. Over time, a better practice emerged: validating data at application boundaries and preserving data integrity within. An example of this is validating user input and sanitizing it to a meaningful format before the data is passed to other code. TypeScript nudges developers in that direction. As we try to increase certainty and replace the any type with meaningful types, validation and type assertions automatically move towards the boundaries of the application.

In this vacuum where we can (to some degree) trust that data has a specific type and format, TypeScript starts to shine. Uncertainty makes room for certainty. This is invaluable. Instead of needing to browse a tree of functions to discover what properties an object needs, we can look up its type or interface. We can write code as if data types are known, avoiding over-defensive code you’ll find in plain JavaScript. Should a type-related bug occur, we know to look at the boundary where the value is validated, parsed, or sanitized, unless someone accidentally type cast the value to something it’s not. Either way, we know where to look or what to look for.

Type annotations enable us to be less distrustful about data. It forces us to think about semantics and data structures and lets us write naive code because data types are known. It gives peace of mind.

Is it worth it?

There’s a cost to all this. Although it removes runtime noise, TypeScript does add syntactical noise that can get incredibly complex. Moreover, the error messages can be puzzling, it adds another dependency to the toolchain, and it’s yet another thing people spend time and energy on that could’ve been spent on learning about (web) standards.

It remains fair to ask the question: is it really worth it?

TypeScript eliminates some uncertainty experienced during development. The effects of that are hard to measure. A (potential) increase in time consumed is one, but there are many more: the number of bugs avoided of any type, the impact it has on the overall code quality, and how it affects the mental state of the developer and their productivity.

The unsatisfying answer is: I don’t know if TypeScript is really worth it, and I don’t think there’ll be a definitive answer. I suppose it’s a gamble, a gut feeling, where the outcomes of all choices are ambiguous.

My gut tells me it doesn’t vastly inflate development time or complexity, and it helps me write better code with more confidence. That’s good enough for me.