Why TypeScript is the Way To Go

Published Sep 10, 2017
Why TypeScript is the Way To Go

I was helping a mentee with some React issues yesterday, and it reminded me why I'm such a big fan of TypeScript. Given my tendency to promote it whenever I can, I thought I'd take a moment and explain why.

Everything has a type

JavaScript doesn't have types, right?


Whenever you work with any object or value in any language, you are making assumptions about that item's contract. In weakly typed languages like JavaScript or Ruby, these assumptions are checked only at runtime. In strongly typed languages like TypeScript or C#, these assumptions are checked at compile-time. Either way, you are working with types.

Consider this JavaScript code:

const className = "active";
const elem = $("#app-root");

In here, we're making a few assumptions:

  • The $ object is a function that accepts strings and returns a JQuery object.
  • The elem JQuery object has a function property addClass that accepts a string as an argument.

Now consider this TypeScript code:

const className: string = "active";
const elem: JQuery = $("#app-root");

It does the exact same thing and makes the exact same assumptions, the only difference is that the types are explicitly referenced.

So what? Well, that means there are...

Fewer bugs!

There are some people who think that static languages don't reduce bugs. The problem with analysis made the in article is that it doesn't consider the bugs that were prevented before the code was delivered[1]. I'm talking about bugs like having arguments in the wrong order, misspelled property names, and incorrect type bugs.

I like to call these bugs "that was never going to work anyway" bugs (or just "noooope" bugs). My mentee's bugs were all like that. The code wasn't returning anything, and never would. You'd rarely see those bugs in any package because they'd be detected during testing (human or automated), but that doesn't mean they weren't prevented during the development process.

And reducing the number of "noooope" bugs means that...

Developing becomes more enjoyable

But what's the big deal? If you look at the JavaScript code, isn't it obvious what the types are? If you're an experienced developer, won't you be able to see these problems without type annotations?

Well, sure! The initial problem is that not everyone is an experienced developer, so they may not know what to look for.

The bigger problem is that when you're developing code of any non-trivial size, the amount of time you spend reading code increases. When you're working with code that isn't explicitly typed, you are taking on more mental responsibility for working out the types involved.

Type annotations save you from the responsibility to work out the types yourself. It makes development easier and more enjoyable because you'd spend less time figuring out what's going on, or debugging "noooope" bugs.

Type annotations (and type checking on compile) also enable huge benefits for developers who use an IDE (and if you don't, why aren't you?). Code completion, documentation lookup, and real-time type checking create huge productivity benefits for developers at all skill levels.


TypeScript[2] + TypeScript-supporting IDEs (Visual Studio Code, Webstorm, etc) save time and make development more enjoyable. Adopt it, and you'll be happy with it.

PS: I've only written a few technical articles before. I'd love to know what you think about this one! 😃

  1. There's also crippling methodological problems with the statistical analysis he references. Bad data is worse than no data. ↩︎

  2. I haven't used Flow yet, but I hear the benefits are very similar. ↩︎

Discover and read more posts from Rich Seviora
get started