A Word on Typescript

A Word on Typescript
Reading Time: 2 Minutes ReadIn my last post, I’ve introduced some frameworks like npm and bower. Now let’s have a word on TypeScript.

Too much talk

There is a lot of discussion on the Internet about the advantages and disadvantages of TypeScript, and how beneficial it is. But how does it compare to BabelJs or Traceur? Why do we need static types in a dynamic language? Is it worth the overhead? Actually, there is a better question: When is it worth the overhead? Let’s take two extremely different examples.

1. Less code fewer problems

Take a couple of hundred lines of code, probably a prototype of an idea, a demo, or something like that. There is not much complexity; a single developer can do it. In this case, BabelJs may be the better choice because it has slightly more ES6 features. You would want to implement this quickly with as little effort as possible. Writing static types on a code that will not be maintained, is not helping much. Yet the advantage of Babel is negligible. Most ES6 features are in TypeScript too, and compilation is easy to set up.

2. “Here be dragons”

Huge projects require vastly different mindsets. Imagine over a 100 000 lines of code, being written by a team of 10 or more developers. The code is already in production, under active support and development. There is a limit as to how much code a developer can see through. If you exceed this limit, you’re inviting mistakes and the cost of a bug is huge compared to a small project. You want to avoid bugs like the plague because they hurt; they hurt a lot. A developer makes a bug accidentally. The QA team notices it. The release is delayed. The sales and deployment team hates the developer. The developer fixes the bug. The QA team checks for regression for a second time. And the later the bug is discovered, the more money it burns. Bugs on larger projects cause larger problems, so every compile-time error of the TypeScript compiler saves money. Static typing, of course, has a certain overhead, but you don’t really care because maintainability is a key. You may be a godlike JavaScript Wizard, who writes maintainable code without static types, but it doesn’t really matter, because you are working on a team. Every team member is at a different level, so it is unavoidable, even with code reviews, that sub-optimal or not-so-readable code gets into the codebase. Managing knowledge in big projects is a challenging task alone, especially when you have a new (junior) developer on the team. It’s easier to see through a 100-line interface than through 1000 lines of code. Large projects aren’t born large. The codebase will have already been through some refactors, which is definitely easier with static types (and their IDE support). It is almost certain that refactoring is impossible without static types, or you need tons of unit tests.

To sum it up:

Static typing is effective when you do it everywhere. It has a certain overhead, but it helps more and more as the code grows.
  • TypeScript has most of the ES6 features, but not as many as Babel though.
  • Types provide discoverability (through IDE support).
  • Autocomplete in the IDE helps to avoid typos.
  • The possibility to refactor helps maintainability.
  • It’s easier to understand the code by the Interfaces, rather than by reading the actual code.
  • Compile time is negligible (it can be parallel and iterative).


Please let us know how we can reach out to you. We will contact you with various options on how you can get an insight and also hands-on experience with AIP.