Last summer we had to convert a huge code base from Javascript to Typescript. During this transition I learned a lot about the differences and similarities of the two. I developed an idea about what makes a good use case for Typescript and when it doesn’t make sense to use it.
Use cases for Typescript
1. Code size: When the source code is huge and more than one person works on the project, a type system can help avoid the obvious errors. This is specially true for SPAs. When someone can change code that potentially breaks another one’s code, it’s generally good to have some sort of safety mechanism. The TS transpiler reveals the obvious mistakes and is kinda smart (but can’t eliminate the need for debugging of course). If the source code is not huge, it probably doesn’t make sense to make it longer by adding type annotations. I have converted 180+ files from JS to TS and in most cases it added roughly 30% to the code size. 2. Previous baggage: if you or the majority of the team come from a strongly typed language like C# and does’t really want to go JS all the way, TS is a good alternative. Even though I recommend learning Javascript for good, there’s nothing preventing you from using Typescript without knowing Javascript. In fact Typescript is made by the same guy who made C# so the syntaxes are similar. In my company we had a team of C# developers who were coding a sophisticated desktop application in C#/WPF (which is front end in the desktop world) and then they were tasked to join my web project as full stack. So it was relatively a shorter path for them to learn Typescript for front end and leverage their C# knowledge for the backend. 3. As a replacement for Babel: The old Microsoft used to take something that is standard (for example Java) and add proprietary non-standard stuff to it (for example J++) and try to force developers pick one. Typescript is exactly the same thing to Javascript (after another try in 1996 divertingJScript from Javascript). Anyway, since ES6 is basically a subset of Typescript and the Typescript transpiler generates ES5 code, it’s practically possible to transpile ES6 code to ES5 (just as Babel) using the typescript transpiler. Though it’s not a strong use case IMHO. Typescript’s transpiler generates pretty readable ES5 code as output and that was one of the reasons Angular 2 team chose TS over Google’s own Dart language. 4. Promoted by lib/Framework: If you are using Angular 2 or another library that makes it particularly interesting to use Typescript, go for it. Just know that even though Typescript can use all Javascript libraries out of the box, if you want good syntax errors, you need to add the type definitions for those libraries externally. Fortunately the nice guys atDefinitelyTyped have made a community driven repo and tooling for that. But that is one extra step when you’re setting up your project (side note: for the JSX fans I should mention TSX).
When you’re better off without Typescript?
1. Extra transpilation tax: There are no plans to support Typescript natively in the browsers (Chrome did some experiment but cancelled later). This means you will always have to transpile your TS code before running it on the browser. For the standard ES6 it’s a whole different story. When ES6 is supported by most browsers, the current ES6 to ES5 transpilation would be unnecessary. ES6 is the biggest change in the language and I suspect most people would settle there, but those who want to try the experimental features of the next version of the language will transpile anyway. You just modify the file and refresh the browser. That’s all — no “watching” or “transpiling on demand” or build system is necessary. If you choose TS, you probably end up doing some extra book keeping for the keeping the type definitions for Javascript library/frameworks up to date (using Definitely typed or writing your own type annotations). That’s something you wouldn’t do for pure JS projects. 2. Weird debugging edge cases: Sourcemaps make it easier to debug Typescript, but the status quo is not perfect and there are really annoying/confusing edge cases that the browser thinks you are running a certain line of code but you are not. Also there are some problems debugging the `this` keyword and properties attached to it (hint: `_this`works in most cases). That is because Sourcemaps currently don’t have a good support for variables (but that might change in the future). 3. Performance penalty: in our project we had 9000+ lines of ES5 Javascript that delivered pure horse power for a WebGL component but we kept it that way. Typescript transpiler (just like Babel), has features and generates code that no matter how good the transpiler is, can’t surpass the optimisations of a good programmer. So we decided to keep it in plain ES5 for ease of debug and deployment (no transpilation whatsoever). That being said, the performance penalty probably is negligible compared to benefits of a type system and more modern syntax for most projects, but there are cases that milliseconds and microseconds matter and in those cases transpilation of any kind is not recommended (even Babel, CoffeeScript, Dart, etc.). That being said, Typescript doesn’t add any extra code for runtime type checking. All the type checking happens at transpile time and the type annotations are removed in the generated Javascript code. 4. Agility: it’s quicker to set up something in Javascript. The lack of type system makes it super agile and easy to change stuff. Sure you can break things easily but if you know what you’re doing, Javascript is more flexible. Remember one of the main use cases for using a type system is to make it hard to break stuff. If Typescript is Windows, Javascript is Linux. In JS land you don’t get the “helper wheels” of a type system and you’re assumed to know what you’re doing but you can ride faster and maneuver easier. Particularly if you’re in the prototyping phase, don’t waste your time with Typescript because JS is simply more agile and flexible. That being said, if you use a typed language, it might be quicker to write/modify code in an IDE because the type system makes it easier to determine syntax. Source: https://medium.com
