Why should we use TypeScript?

(This is a re-publication of the same title article written in 2015 here)

What is TypeScript?

TypeScript is a language which is a superset of Javascript (JS), meaning any JS code can be safely compiled by TypeScript transpiler. TypeScript was created by Microsoft but it has been developed as an Open Source project. Google’s Angular team was once decided to build another language, AtScript, as a superset of TypeScript, but eventually they will just use TypeScript for their new Angular 2 framework.

TypeScript provides following features:

  • ES3/ES5 code generation. (Note: most today browsers support ES5 JS specification)
  • Type annotation
  • ES6 modular: module and class keywords.
  • Support AMD/CommonJS code generation.
  • Other ES6 features (e.g. string template, arrow function. More on ECMAScript 6 compatibility table)

The most important feature of TypeScript is Type Annotation which allows static type analyzing through TypeScript transpiler.

Why Type Annotation matters?

Because JavaScript was originally designed to be a linker between HTML and Java applet. The language did not provide modularity design and was intended for writing small controlling script. Though Javascript has been used to write business application for over a decade but it was done with cooperation of server generated content (e.g. CGI, ASP, PHP). Today, an entire application can be written only in Javascript. Many business functions and data structure which once used to live on server side (and was often written with more feature-rich language), now resides in in client side! Writing a complex application in weaked-type, dynamic language is similar to writing an application in Assembly language, which requires disciplines, good practices, and good documentation (in a form of comments or unit tests).

The thing that can easily obfuscate Javascript code is complexity of data structure. UI application may not need type annotation as concept of UI components is quite well-known of developers and becomes developer’s “common sense”. For example, most developers who used to work with UI should know that most UI components employ some kind of “text” property which allows developer to set its display content. And by the “common sense”, they should know that text requires string data type. But this is not always possible when working with APIs or calling external services which provides their own data structure, especially if it has not enough API documentation, developers can waste significant effort in order to understand and use the services.

Risk of using TypeScript

Apart from being maintained by Microsoft team (with some contributions from its community), using TypeScript in a project is considerably safe, as the language itself does not introduce non-standard features. The compiled, JS code will look like the original TypeScript code most of the time. For example:

TypeScript code

interface Point {
 x: number;
 y: number;
function add(p1: Point, p2: Point) :Point {
 return { x: p1.x + p2.x, y: p1.y + p2.y };
var z = add({x: 1, y: 1}, {x: 2, y: 2});

Compiled Javascript code

function add(p1, p2) {
 return { x: p1.x + p2.x, y: p1.y + p2.y };
var z = add({x: 1, y: 1}, {x: 2, y: 2});

What is missing is that just type annotation has been stripped off. If in the future there is no need for TypeScript code, then we can just use compiled JS code without any extra efforts required.

Note: This holds true if we only use Type Annotation. But if we also use some ES6 features, like module/class, and target on browser that does not yet support ES6, it has to be compiled into ES3 or ES5 script and the code will look somewhat different, but not radical.

Other benefit: Intellisense support

In addition to type checking, with type information editor can use this information and provide intellisense dropdown when developer is coding in TypeScript. Major editors have support for TypeScript in a form of plugins (e.g. Sublime, Atom, Visual Studio 2013 or lower). Visual Studio Code and Visual Studio 2015 natively supports TypeScript.

Type information also benefits Fluent-style API design. With intellisense, it can provide library that is designed with fluent-style to be easily navigated. Moreover, TypeScript’s type inference sometimes makes type declaration unnecessary, which allows writing code more easier. For example, the following TypeScript does not declare any type but TypeScript transpiler can still detect a mistake:

function getData() {
 return {x: 1, y:1};
var data = getData();
var z = data.z; // TypeScript transpiler will report error from missing ‘z’ in data structure {x:number, y:number}

Technically, what can prevent us from using TypeScript?

Generally, TypeScript should be able to be used with any JS libraries which target ES3/5 browsers. But there can be issues if using TypeScript with other transpilers. The solution is depended on the types of conflicted transpiler. For examples:

  • Browserify is a transpiler that rearranges and packages JS files by their dependency declaration (in CommonJS spec). This kind of transpiler can still work with TypeScript but it has to be run after TypeScript.
  • Babel is ES6 polyfills. It supports some ES6 syntax which is more advanced than provided by TypeScript. If you use Babel, it has to compile code before passing to TypeScript since it does not understand Type system. Thus, using Babel or TypeScript becomes an mutual-exclusive option.


To use TypeScript or not, in my opinion, is based on size, complexity, and number of team members involved of JS project. If you are to build a prototype, or a short-term project, TypeScript may be an obstacle then help. But if the project is going to be maintained for years, robustness of Type system may be a benefit.

Future of TypeScript

TypeScript team plans to include more ES6 features into the language. You can check out TypeScript wiki page [2] to see the advancement of the language.

What is more interesting is that TypeScript may support Reflection ability[3] that allows other JS code to discover functions/classes. When available, TypeScript would enable Dependency Injection pattern to JS world, which should also improve unit test framework and plug-in architecture. With all of these, a complex application can become easier to maintain.

Note: Some present JS library has implemented their own Dependency Injection pattern via a form of annotation. The feature should allow omitting the annotation form entirely.


  1. TypeScript homepage
  2. What's new in TypeScript (GitHub)
  3. Decorator and Metadata in TypeScript