TypeScript for JavaScripters

Some background

A few months ago I blogged about TypeScript on production. In the post I talked about my first experience with TypeScript and how we integrated it into an existing pure JavaScript project.

Many people are starting to get interested in TypeScript and are asking (with some fear) questions, and how can they benefit from moving to TypeScript. So I've decided to blog about it, so everyone can gain.

What’s going on today

According to Wikipedia, EcmaScript 6 specifications are planned for Dec. 2014. FireFox has already implemented many of the features, Chrome are pushing hard too, we have Node Harmony, and even IE11 already implemented the Let, Set, Map and much more.
So things are looking good, and will be much better in the near future. But till then we have TypeScript (Version 1.0 was released not long ago)

Why would you want Types?

If you write your code with tests (and you should), you probably know the feeling when a test fails. “Yeah, I didn't do that right; I should have sent this object and not that one.” It’s a very human thing to make mistakes, and the tests help you find them before you even run your code.

The same goes for Type Safe coding. It is actually a test that needs to pass before you run your code. If you told the test that a function must receive 2 string parameters, any call to this function should fail if it didn’t do that. That’s what happens in the compilation of TypeScript code.

Besides testing your code types, TypeScript provides many more features like classes, interfaces, generics, arrow functions and much more. All these features are planned in ES6 and are implemented in TypeScript, so once the world is ES6, you are too.

"Classes and Interfaces, Ugh!"

You may argue that Classes and Interfaces and bad things, and you are very comfortable with the module pattern. This is great and you can keep doing that, TypeScript does NOT force you to do Classes and Interfaces! 

In my mind, there are some situations that classes and interfaces are very welcome, and should be used, and there are places that functional programming is the right thing to do. choose your style.

"I hate generated code"

Me too! most of the debugging that I do, I do it on the browser.
The TypeScript generated code is very similar to the code that you write, with some additions.
The types are omitted, the names of the variables, functions, and modules remain the same, your comments are still there, so you will have no problem debugging TypeScript generated code. Belive me, I've been doing for this for the past year with no problems at all.

Remember: ANY existing JavaScript code is a valid TypeScript code.

3 Baby steps


If you're a JavaScript developer who enjoy the freedom of the language, keep doing that! TypeScript will not do anything to your code – nothing!
But, if you find a place that you want to be more strict – for example, specify a function parameter type as string – TypeScript will help you enforce that, just like a test. And after the compilation, all the type definitions are removed and your code will be as it would have without TypeScript. You just added a test.


The next step I would suggest is to start using modules. The Module Pattern is well known in the JavaScript world, and many developers are using it to namespace their code and hide code that they consider private.
TypeScript implemented the module pattern and it’s very easy to use. It’s a much more organized code, and it’s loadable using commonjs or AMD .

Arrow functions:

In pure JavaScript, you have to make sure that “this” is the right ”this” all the time. Callbacks from events will have the caller’s “this” and not the callback owner. To solve this issue, people use “that” or “_this” and there’s the “bind” and “unbind.”
Those days are over. From now on you should use the arrow function; it will generate the “_this” behind the scenes for you (you can see that on the generated js files).

For starters, this is more than enough to get you started and get your feet wet. So I’m not going to talk about classes, interfaces, generics, and all the other great stuff… :-)

Before you start

  • Use Grunt to compile your code, I would suggest using grunt-ts as it has more features over the grunt-typescript task.
  • DefinitelyTyped is a great repository for type definitions for existing libraries like AngularJS, JQuery, or anything you can think of.
  • WebStorm and VisualStudio are the best IDEs for TypeScript, but if you don't like it, be sure that your current IDE supports TypeScript.
  • Like all Compile-to-JavaScript compilers, TypeScript offers source maps to be used for debugging your original code.
  • You can play with TypeScript here
  • ES6 is a great language for small, medium, and mostly large apps. Read about it; after all, it’s coming soon, and you don't want to be left behind.

Traceur (By Google)

Traceur is yet another Compile-to-JavaScript, with more features implemented vs TypeScript. It aims to be exactly aligned with ES6 specs. But types are experimental feature (for now), And it can compile your code at run-time (Just like a browser would).
The only downside that I see is the generated code, it looks very complicated and I guess that with Traceur you must use source maps to debug your code.


Not all the features are implemented in TypeScript just because they don't want to generate a complicated js file (Like you see in Traceur), for example: the Let command was not implemented because it meant inner scope and variable duplication. But the current version has many features implemented, and it’s more than enough to get your feet wet in the ES6 world.

Related Posts


  1. Great post! I believe it would be valuable to mention source maps for debugging. I usually debug in Chrome which provides me the original .ts file to debug rather than the compiled version.

  2. Cool staff!!
    any change to get a link for the slides that you present at Wix event at 2/2/16?

    1. http://slides.com/gilamran/basic-to-adv-typescript-4-2-3#/


Powered by Blogger.