It‘s worth being said that it wasn’t my intention to move to TypeScript instead of vanilla JS. It just happened that we decided to move our production-ready project to Angular 4, which, as all of you know, uses TypeScript as a default language. Despite the fact that Angular projects can also be written in plain JavaScript, it’s documentation, examples, and most of the answers at StackOverflow are written in TypeScript. So, the decision was made and I have no single regret of doing that. Let me explain why.
TypeScript provides us with a bunch of advantages that are not implemented in ECMAScript aka JavaScript yet. So, let’s discuss them one by one.
Types
For those of you who didn’t work or hear about TypeScript:
…it is a typed superset of JavaScript that compiles to plain JavaScript
It becomes obvious from the language name that the main difference lies in the fact that TS uses types. So, yeah, it is strongly typed language, the feature that about 50% of JavaScript developers were missing and the remaining 50% hate in other strongly-typed languages. Without referring types of responses or other data, we had a lot of freedom in our code but at the same time this freedom is the main reason for lots of errors that are hardly debuggable (not sure if such a word even exists).
From my perspective, types are great. They make your code more accurate and understandable for other developers. It makes much easier to see what method returns when you intentionality define its return type and it also prevents you from returning something else. The second benefit of typing is to see the response type of your Http request. We all know how painful it may be in JavaScript to debug errors when your code doesn’t work properly and the reason for that is that you’re referring to a response property which may not exist at all. Therefore, declaring response type prevents you, a developer, from this headache.
Classes and Interfaces
For those of you who gonna tell me that ES6 introduced classes, my response would be “Yes, I know that”. However, typescript is not just about classes and types. If not mentioning that TS classes also provide us, developers, with public, private, static, readonly members of classes, it also introduces to us Abstract Classes and Interfaces, which we do not currently have in JavaScript.
Abstract Classes are a part of more advanced topics of OOP rather than TypeScript but still, they are worth mentioning. Here’s a quote from the official TS documentation:
Abstract classes are base classes from which other classes may be derived. They may not be instantiated directly. Unlike an interface, an abstract class may contain implementation details for its members. The abstract keyword is used to define abstract classes as well as abstract methods within an abstract class.
The simplest and the most vivid example of Abstract Class is:
abstract class Animal {
abstract makeSound(): void;
move(): void {
console.log(“roaming the earth…”);
}
}
Interfaces are another great feature that was introduced in TypeScript and which is actually used on a daily basis compared to Abstract Classes. Generally, in Typescript, interfaces fill the role of naming your own data types, and are considered a powerful way of defining contracts within your code as well as contracts with code outside of your project. It means that interface helps you define the skeleton of classes or data types, while their actual implementation may differ.
Public, Private, Protected, Static, Readonly Modifiers
As it’s been mentioned before, ES6 introduced classes to JavaScript developers, but it missed one important thing — modifiers. Since TypeScript is a more advanced and progressive version of JavaScript, it successfully fills this gap. With such modifiers as public, private, protected, static, readonly, we are able to enclose variables, properties, and methods into the corresponding scope. Plus, it is no longer needed to use different workarounds like IIFE or revealing patterns. With TypeScript, you can easily define which fields and methods should be accessible outside classes and which should not, which ones we allow to change and which should always remain unchanged.
Namespaces and Modules
Comparing to ES6, which has modules to help developers organize their code, TypeScript also gives them such a nice thing as namespaces that are heavily used in other OOP languages like C#.
Briefly speaking, namespaces are a way of organizing code, dividing it into different parts, which gives us an access to the code from the other parts of an application.
Using namespaces is especially useful when you do not want to spoil the global scope with a bunch of variables. Apart from that, interfaces are very handy when the application is quite big and we want to split the code across multiple files to make it easier to maintain in the future.
TypeScript Is Still JavaScript
The last but not least thing I’d like to mention is that TypeScript is still JavaScript. TS is based on ES6 features and does not provide new methods or change the existing ones. If you compile your TS code into JavaScript, you will see the same Prototypical Inheritance. You will never see in a compiled JS code interfaces, decorators, modifiers — they just do not exist. Therefore, it is just a layer on top of JavaScript, which improves the experience of developers and prevents lots of unnecessary bugs from happening.
On top of that, you are free to choose to which version of JavaScript your TypeScript code will be compiled, which means it will run even in Internet Explorer.
Don’t take me wrong, I am not telling that we all should stop writing in JavaScript and move to TypeScript. JavaScript is a great language with an increasing pace of development. Its popularity is growing from year to year and now it is one of the most popular and frequently used programming languages. Still, there are a lot of areas for future improvements, and that’s where TypeScript comes into play.
Top comments (5)
@Vladyslav
Great points. One other option is that we can easily use plain ole Javascript in Typescript if we want to do that. I try not to do that because I want auto-completion for everything.
Excellent article! There is only one statement to this that I'd like to point out.
"You will never see in a compiled JS code interfaces, decorators, modifiers — they just do not exist". Not quite. Typescript has the option to emit metadata into the Reflect API which can be polyfilled. All interfaces, types and classes gets compiled into regular Javascript code with the global JS objects acting as types. Like String instead of TS's string. This is actually what makes the Angular DI system work.
The best part being, it's opt in. You can incrementally update your existing JS project to TS without impacting the current code :)
I also like how it infers the types automatically for generics passed as well.
you're totally right) but from my experience can say that sometimes it's quite painful if the project is quite big
Coming from static typed language OOP langauge, Typescript looks familiar and easy to work with.