In 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.
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).