This article is now available in Japanese and Chinese.
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.
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.)
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 There are no plans to support TypeScript natively in the browsers. Chrome did some experiment, but later cancelled support. I suspect this has something to do with unnecessary runtime overhead.
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.
For standard ES6, it’s a whole different story. When ES6 is supported by most browsers, the current ES6 to ES5 transpilation will become unnecessary (update: yes indeed!).
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.
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.).
For our project it made sense to use TypeScript. I tried to refactor some of my hobby projects in TypeScript but it sucked. I personally like 4 things about TypeScript:
1 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.
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.
Here is a quick tutorial, and a very nice guide, but I’m more a language-reference kinda guy. If you like video, here’s a course from Udemy.
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.