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.
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.
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.
Static typing is effective when you do it everywhere. It has a certain overhead, but it helps more and more as the code grows.
Links
