by Alex Ewerlöf
When should I use TypeScript?
When it makes sense to use TypeScript
When you have a large codebase
When your codebase is huge, and more than one person works on the project, a type system can help you avoid a lot of common errors. This is especially true for single-page applications.
Any time one developer could introduce breaking changes, it’s generally good to have some sort of safety mechanism.
The TypeScript transpiler reveals the most obvious mistakes — though it won’t magically eliminate the need for debugging.
When your team’s developers are already accustom to statically-typed languages
In my company, we had a team of C# developers who were coding a sophisticated desktop application in C# and WPF (which is basically a front end development tool for the desktop world). They were then asked to join a web project as full stack developers. So in short order, they were able to learn TypeScript for the front end, then leverage their C# knowledge for the back end.
TypeScript can serve as a replacement for Babel
The old Microsoft used to take standard tools — Java for example — and add proprietary non-standard features to them — in this case resulting in J++. Then they would try to force developers to choose between the two.
Though it’s is a less-common use case, it’s technically possible to transpile ES6 code into ES5 using the TypeScript transpiler. This is possible because ES6 is essentially a subset of TypeScript, and the TypeScript transpiler generates ES5 code.
Also, TypeScript has some cool features that are not in ES6, like enums and the ability to initialize member variables in a constructor. I’m not a big fan of inheritance, but I find it useful to have the public, private, protected, and abstract keywords in classes. TypeScript has them and ES6 doesn’t.
Our C# developers thought it was super amazing to be able to write a lambda function as the body of a method — which eliminated the headaches associated with the this keyword.
When a library or framework recommends TypeScript
If you are using Angular 2 or another library that recommends TypeScript, go for it. Take a look at what these developers have to say after using Angular 2 for six months.
(On a side note: for all you JSX fans, check out TSX.)
When you really feel the need for speed
if(typeof name !== ‘string) throw ‘Name should be string’
With TypeScript, we could eliminate a lot of these type checks all together.
This especially showed its effect in parts of the code where we previously had a performance bottleneck, because we were able to skip a lot of unnecessary runtime type checking.
So when are you better off without Typescript?
When you can’t afford an extra transpilation tax
If someone wants training wheels, they can install them. But bikes shouldn’t come with permanent training wheels. This means that you will always have to transpile your TypeScript code before running it in a browser.
Without transpilation, you just modify the file and refresh your browser. That’s it. No watching, transpiling on demand, or build system are necessary.
When you want to avoid weird debugging edge cases
Sourcemaps make it easier to debug Typescript, but the status quo is not perfect. There are really annoying and confusing edge cases.
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 — though this may change in the future.
When you want to avoid potential performance penalties
The TypeScript transpiler (just like Babel) has features that require generating extra code (inheritance, enum, generics, async/await, etc). No matter how good your transpiler is, it can’t surpass the optimizations 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 is probably negligible compared to benefits of a type system and more modern syntax for most projects. But there are cases where milliseconds and even microseconds matter, and in those cases transpilation of any kind is not recommended (even with Babel, CoffeeScript, Dart, etc.).
When you want to maximize your team’s agility
There is no one best language overall. But for each individual project, there is probably one objectively best language and library and framework and database and operating system and… you get the picture.
For our project it made sense to use TypeScript. I tried to refactor some of my hobby projects to TypeScript but it did not worth the effort.
I personally like 5things about TypeScript:
- It’s fully compatible with ES6. It is really nice seeing Microsoft playing fair with the other browsers. Our ecosystem can benefit from a strong rival to Google, Mozilla, and Apple. Microsoft is spending serious energy on it — such as writing Visual Studio Code from scratch using TypeScript on Google Chrome, of all platforms.
- The type annotations are like a basic level documentation. They declare the type of data that each function expects, their results and various other hints like
Typescript is not the answer for everything. You can still write terrible code in it.
TypeScript haters are gonna hate, either because of fear of change or because they know somebody who knows somebody who is afraid of it. Life goes on and TypeScript introduces new features to its community anyway.
But like React, TypeScript is one of those influential technologies that is pushing the boundaries of our web development.
John Papa has a a short article about ES5 and TypeScript.
There’s an interesting study that shows all things equal, a type system reduces bugs by 15%.
Oh, and if you feel like going on a side mission, read why programming is the best job ever.
⚡️Liked what you read? Follow me to be notified when I write something new.