So, what’s TypeScript?

A few days ago, Microsoft introduced TypeScript. Many IT news websites defined TypeScript as a “Super Javascript” from Microsoft, but what is it really? Why was he crafted? What are Microsoft plans going forward?

When Niels Nijs asked me about TypeScript, I noticed it was in fact a very good example of the Forward Polyfill philosophy. It was therefore interesting to speak a bit about it on my blog.

Why JavaScript isn’t sufficient

When you’re working on small scripts, JavaScript is a very handy language. Because of its ample degrees of freedom, it’s possible to get something working quite quickly.

However, when you’re making libraries and components for more important projects, JavaScript is really cumbersome because there’s no good way to “hide” private implementation-related mechanisms from the core functionalities.

This means that the degree of coupling in your code quickly becomes unmanageable and this will hurt your maintainability on the long run.

It’s very possible that small mistakes will stay unnoticed until runtime because they’re difficult to spot, which can make your web apps less reliable than you would like.

Also, renaming variables and types is very difficult, given the “dynamic” nature of JavaScript.

What TypeScript adds

TypeScript isn’t a super JavaScript. TypeScript is a superset of JavaScript. That means that any JavaScript code is also a valid TypeScript code.

This also means you can continue to use the JavaScript libraries you know and love (jQuery, Knockout, …), even if you can’t find any TypeScript interface for them.

However, TypeScript allows you to give an “indicative” type on variables, function parameters and return values (hence the TypeScript name). This will help the Visual Studio IDE to provide you the good refactoring experience (intellisense, go to definition, rename, find all references, …) you already know and love when working with C# or VB.

Additionally, Microsoft added a few syntax constructions of ECMAScript 6 to its compiler (the current JavaScript version supported by most browsers is ECMAScript 5).

This includes C#-like lambda expressions, classes and namespaces (modules).

Classes and modules give you the opportunity to define “public” or “private” constructs that will or not show up in the intellisense at relevant places.

This helps you to keep your code reliable and coherent.

Where’s TypeScript going to

TypeScript is Microsoft’s forward polyfill implementation of JavaScript. That means that it will evolve in pair with JavaScript so that both stay in sync regarding their syntaxes.

This is why I call TypeScript a “Forward Polyfill” : it allows you to use parts of the futuristic syntax and features of JavaScript on the existing JavaScript infrastructure.

It’s very likely that your TypeScript code will become (with very few changes) a valid ECMAScript 6 code when browsers will start to support it.

However, as JavaScript will evolve to embrace some features introduced in TypeScript, new things will appear in TypeScript. As such, TypeScript is an experiment for Microsoft: what is good in TypeScript should be added to JavaScript, and what was proven bad should be forgotten.

For Microsoft, the goal of TypeScript is to provide better tools for JavaScript, not to replace JavaScript with some new language. This is why this is so different from CoffeeScript or Dart, which aim to replace JavaScript on the long run.

Microsoft made the choice to embrace JavaScript with a set of open-source IDE helpers, and their goal is to make the developer’s life easier.

Whether their attempt will succeed is yet to be determined. But given Visual Studio 2012’s outstanding native JavaScript support, I bet TypeScript can’t do anything else but confirm this excellent profile. I’m already looking forward to the next Visual Studio version which will have native TypeScript support.


Published on 2012-10-06 under ALL, JS, WEB


A javascript file is loading the comments.