How My Team Accidentally Moved to TypeScript and Loved It

Like many web developers, I had limited exposure to strongly-typed languages, but when TypeScript arrived, my team dove right in.

Like many front-end developers, I was really excited by the release of Angular 2.0. I had been using AngularJS for a couple years, and my team at the time had started to feel some of the pain of building large projects with it. Angular 2 seemed to solve many of those issues.

When I got the opportunity to join a new team and start a greenfield front-end project in late 2016, I figured that Angular 2 would be a good fit. Since TypeScript was the default language, that's what we ended up using.

While our decision to use TypeScript wasn't intentional, we had heard some of the supposed benefits, and we were excited to try something new on the front-end. For two decades, JavaScript has been the go-to option for front-end development, so, while TypeScript is technically a superset of JavaScript and it ultimately compiles to JavaScript, it has enough new features that it's worth making a distinction.

Our new front-end project is almost two years old now, and we've gone from Angular 2 to Angular 5, with plans to upgrade to version 6 soon. As the project has grown, we've reaped a lot of the benefits of both Angular and TypeScript, and while I'm still a fan of Angular, my team and I have become even bigger fans of TypeScript. For that reason, I'd like to share with you our thoughts on the language; what we like, what we love, and some things to watch out for:

• Strong Typing Decreases Bugs, Improves Refactoring Process
• TypeScript Improves Code Readability and Minimizes Documentation
• TypeScript is Friendly to Object-Oriented Developers
• TypeScript Forces You to Think About Design, Code Organization
• Browser Compatibility
• But, TypeScript Isn't Perfect...

Let's begin!

Strong Typing Decreases Bugs, Improves Refactoring Process

Like many web developers, I have had limited exposure to strongly-typed programming languages. The dominant languages of the past decade — JavaScript, PHP, Ruby, and Python — are dynamically-typed, meaning that variables can change their type at runtime. While this makes them great for rapidly prototyping new software, it also makes them unwieldy as teams and codebases grow.

Let's take a look at an example of how strong typing can make bugs harder to introduce. A typical JavaScript function that deletes a user via an HTTP client might look like this:

function deleteUser(user) {
  return client.deleteUser(user);
}

Looking at this function, it's impossible to know exactly what fields the user variable must have or what the client.deleteUser() method will return. You can figure it out by following each call through the stack or using a debugger, but in TypeScript, it becomes very obvious what your function's input and output must be:

function deleteUser(user: UserObject): Promise<boolean> {
  return client.deleteUser(user);
}

This tells us that the user variable must be a UserObject and the deleteUser() method must return a Promise of a boolean. If any of these inputs or outputs is not correct, the TypeScript compiler will catch the error before you even run your application. This prevents a ton of bugs and mistakes from being shipped to production.

TypeScript Improves Code Readability and Minimizes Documentation

One thing I didn't realize about strongly-typed languages before I started building in TypeScript was how often I end up documenting inputs and outputs in DocBlocks to improve readability and code comprehension. For example, in JavaScript, I might append the above function like this:

/**
* Delete a user and return success or failure promise
* @param UserObject
* @return Promise<boolean>
*/
function deleteUser(user) {
  return client.deleteUser(user);
}

That's a lot of lines to accomplish what TypeScript does with a few keywords embedded in the function itself.

The other problem with relying on documentation is that it's tough to keep it up to date. While I do believe that code comments are sometimes necessary, it's pretty clear to me that strong typing helps TypeScript self-document better than most dynamically-typed languages. It's always better to rely on code as documentation when possible.

TypeScript is Friendly to Object-Oriented Developers

While functional programming has seen a resurgence in recent years, for the past decade, most developers have been focused on object-oriented design and patterns. JavaScript is not a traditional object-oriented language, as it lacks classes (despite the ES6 sugar), interfaces and class inheritance. None of this is a bad thing — if you read Douglas Crockford's book, JavaScript: The Good Parts, you might gain some appreciation for it — but it's a conceptual leap that programmers coming from C#, Java, or PHP might balk at.

TypeScript adds features that make front-end development more familiar to object-oriented developers. In TypeScript, you can create and extend classes, implement interfaces, create abstract classes, set member access, use static properties and methods, and much more. While all these features compile down to standard JavaScript in order to be run in the browser, having these object-oriented features can be helpful for making the leap to front-end development.

TypeScript Forces You to Think About Design, Code Organization

I like working with junior developers, but one thing I notice is that they tend not to think ahead when building a new feature. While a senior engineer might spend 75% of her time thinking and 25% coding, a junior engineer might do the reverse and spend 25% of her time thinking and 75% banging away at code. TypeScript — due to its strongly-typed nature — can make developers stop and think a little more.

For example, the following function is valid in JavaScript:

function isComplete(finished) {
  let placeholder = false;
  if (finished === true) {
    placeholder = 'complete';
  }
  return placeholder;
}

But in TypeScript, a variable like placeholder which changes from a boolean to a string would not be allowed. This minimizes the use of lazy catch-all variables or objects like placeholder in the above example, and makes developers choose accurate interfaces and types for their variables and consistent return types for their functions.

Browser Compatibility

While not exclusively an advantage of TypeScript, the fact that you can set the compilation target for TypeScript using webpack or Grunt means that you can work in the modern, strongly-typed language while you're developing, yet still serve up compliant JavaScript to any browser. My team's legacy application was written in vanilla JavaScript and jQuery, so we had to be careful about what features we used and didn't in order to make sure our site worked in older versions of Internet Explorer. Now that we've switched to compiled TypeScript, we don't have to worry about whether a feature is universally supported or not.

But, TypeScript Isn't Perfect...

While my team has been happy with the change, and we've reaped plenty of the benefits of using TypeScript, using the new language hasn't come without its tradeoffs. In fact, for some smaller projects, you may find that TypeScript slows your team down. If you've already got a robust test suite, you may not feel as much need for strong typing.

Some of the considerations we've noticed after switching to TypeScript include:

• TypeScript requires an IDE for maximum effectiveness. On the plus side, Visual Studio Code is free and made to work with TypeScript.
• You have to plan for typing up front to get the full benefit. When we first started using TypeScript we weren't very careful with our null typing, so when we later tried to implement strict null checks, the compiler failed all over the place. If I were to start a new project, I'd make sure all the typing rules were in place before I wrote any code.
• You can still abuse union and any types to avoid true strict typing.
• Developers have to think ahead, write more interfaces and type their objects. This can slow down developers at first, but, again, the advantages of TypeScript become clearer the larger your codebase gets.
• Not every library you use will use TypeScript. This means that you'll either have to build your own Declaration File or lose the advantage of strong typing in the part of your code that interfaces with the third party code.

Despite these minor "gotchas," TypeScript has allowed our codebase to grow in a maintainable and organized way at The Graide Network, and I'm really glad we accidentally made the switch.

Related Blog Content You May Be Interested In

• Why TypeScript Might Be a Good Fit for your Next Project (with Video)
• What is TypeScript
• How to JavaScript in 2018