TypeScript on production!

What's going on today?

The current version of JavaScript that you see in most modern browsers uses the ECMAScript 5 standard. The next version, ECMAScript 6, is still not determined, and is still under development.

ECMAScript 6 is supposed to include many of the missing features such as classes, modules, iterators for for/of loops, arrow functions, collections and more! These features will allow developers write big and complex applications with JavaScript.

Even after the specifications will be released, it will take some time until it will be available to the majority of the public's browsers. This means that if you want to develop a web-app or just write something for the web, you must use ECMAScript 5 standard.

Today, companies that develop big and complex web apps with more than a few developers must find a way to handle huge amount of prototype-based, un-typed, fragile code. The more code/developers you have in your project, the unhappier you will be with pure JavaScript.

There are many solutions out there: some build their own in-house class framework, some use open-source class frameworks. Also, there are the new languages like Dart, CoffeeScript, Haxe, and many more, and now TypeScript.

What is TypeScript

TypeScript is another JavaScript replacement; actually it's a super-set of JavaScript, and it extends the current JavaScript. This means that you can still write JavaScript code inside TypeScript code, and it will compile with no problems (yes, you have to compile your code)

So, the basic idea behind TypeScript is that it is ECMAScript 6 compatible, while supporting the current version ECMAScript 5. This is the biggest benefit that it has over the other JavaScript replacement languages.


  • Compile time type-checking (Dynamic typing).
  • Classes and Interfaces, function visibility, and all the benefits of inheritance.
  • Modules.
  • Generics.
  • Intellisense, code completion and refactoring.
  • Definitions for existing libraries.
  • Output human readable JavaScript code.
  • Compatible with the current JavaScript!
  • Open-Source (Apache 2).
All the pros we have with TypeScript are huge time savers for existing JavaScript developers, and TypeScript is very welcoming for existing Java, C#, C++ developers.
You can actually take your current JavaScript code and add TypeScript to it with no problems, do the migration slowly, and only to the parts you select.


  • No packages, only modules.
  • Compilation time.
  • Debug code that you didn't write (you can use maps).
  • Type safety will never be part of the ECMAScript specs. so you'll always have to stay with TypeScript, if you want Type safety.
The most problematic issue is the modules; the other cons are easily acceptable. A developer coming from Java or C# is used to the package model; TypeScript uses the modules pattern, a different way to scope your code. ECMAScript 6 will use modules and not packages (TypeScript follows this concept) and modules are good for loading parts of your code on demand (look at AMD).

Before TypeScript

Our project was constructed with a Java back-end, and a single page application, JavaScript/HTML.
We didn't build an in-house JavaScript class framework, nor use an external class framework; we used a pure prototype inheritance approach. (Yuck)
We decided to go that way to save time and get the product out as soon as was possible, we had to prove the need for this product.
These days we "pay" for the "speedy" development, with hard refactoring (if we dare), and new features are not being implemented so fast anymore... But it was taken into account, and now we have some time to build things right.

The JavaScript frameworks that we did use were JQuery, JQueryUI, and HandleBars a very minor setup according to web-apps standards these days.

Now that we know for sure that our product is worth the effort. We started thinking on how to do the refactoring without harming existing code.

This is where TypeScript came into the picture.

The beginning of the transition

First we started using Node and Grunt to do the minifying of the code and CSS (First versions were not even minified!). We've also added tests with Karma.

When we felt more up-to-date with the world of Front End Developers, we decided to try out TypeScript, mostly because of all its features and its ability to assimilate into existing JavaScript projects with ease.

I started by taking existing parts of our code (BI Manager) and rewrote it in TypeScript. This gave me a feeling of the language and the workflow.

Working with TypeScript


The first thing that was important is the IDE. We use IntelliJ IDEA, and we were lucky to find out that the latest version (12.1.4) supports TypeScript code. I gave it a try.
After some minor configurations, I managed to compile TypeScript code on save of files, with errors and hints on the code. Intellisense and code completion works great!
If you don't use IntelliJ, you should consider Visual Studio, as they integrated TypeScript very well.

Code Generation

The language itself (as you can imagine) was quite a surprise! All the language features are being translated into the JavaScript prototype perfectly. The generated code is totally readable, and debuggable. I even decided to debug only the generated JavaScript code, and not use source maps. It was surprisingly easy; I sometimes didn't even remember that I was looking at a generated code. It felt like my own code; it was not one to one, but was very familiar.


IntelliJ can help refactor your TypeScript code, but it is not something that I would currently use. Any class variable should be accessed using the ‘this’ keyword. When using refactoring with IntelliJ, it will remove the ‘this’ from all the refactored items. I guess that it will be fixed soon.
Again, I know that Visual Studio is doing great job in the refactoring area.

External references

When you change a TypeScript code and save it, your IntelliJ watcher will detect that, and will compile the code on the fly. Sometimes you can change a code that is being referenced by other modules, you can break the code without knowing. These modules should also get compiled, and any errors caused by your change should be raised at the time of your change. This does not happen as of today.
The obvious solution is to detect errors on the full project compilation.

Working with existing libraries

When working with existing code or libraries you should have a definitions file, a file that defines the interface to existing code that was written in JavaScript. This can be your legacy code, or an open-source code like JQuery that was written in JavaScript.
You can find more than 90% of all the common libraries definition files at DefinitelyTyped.

The project

I'm working at Wix.com, [THE best website builder e-v-e-r :-)]
I'm on the eCommerce team, and we build the store manager. The next thing planned was the Orders Tab. After "playing" with TypeScript on the BIManager (a closed module in our system), we decided to go for TypeScript and build the Orders Tab with it.

Here's the product design, done by our UX team:

This tab is isolated (in logic too) from the other tabs, so doing a separate module in TypeScript was not a scary thing; at any time we could just take the generated code and continue from there.

I have decided to go a bit bigger and go full MVC structure, while still using the existing JQuery and HandleBars libraries.

The code structure


To achieve working MVC pattern you should have an EventDispatcher (observer pattern) in your arsenal.
Coming for AS3 and Flash, I've have decided to implement the EventDispatcher in TypeScript. This was very straightforward and easy to implement.


The Model is pure TypeScript code which dispatched Change events.
The View is generated using HandleBars, and the Controller uses the view and notifies the model, nothing special here.
It was very easy to implement it using Classes and Interfaces. The language was flawless, and I was thinking about the logic and not on how not to mess things up, a feeling that I always had when developing with pure JavaScript.
I know that I could use BackBoneJS or any other MVC framework (all the TypeScript definition files are available online), but we didn't use them in the JavaScript code, so I didn't want to use something new while coding in a new language. Next time, this is definitely a valid option.

The result

The result was surprisingly similar to the design that was given to me, and I was quite happy with the result. But this has nothing to do with TypeScript, this could be achieved in any language.
The most notable thing that was achieved here is that I now feel that there's a real and working solution for medium/big web-app projects!
Developing the same project using JavaScript would have taken much more time, I'd say up to two times as much time!

The near future

First of all, we want to progress a bit more regarding the frameworks that we use and tryout AngularJS or EmberJS (I'll probably blog about it).
I will investigate the Modules a bit more and see how we can use AMD in our project.
There are some new features in TypeScript 0.9 like Generics that I want to investigate and get to know better.
Besides me, the rest of the team is learning TypeScript, reviewing the code, fixing bugs, and even writing new code with it.


TypeScript is a refreshing change from all the problems of the old JavaScript: you can count on TypeScript for your next project, as well as existing projects. It worked well, and it is still working well, and I don't see any good reason for going back to JavaScript anymore.

There are still some minor issues with the IDE, but this has nothing to do with the language itself. Things are looking great for this language.

Using TypeScript is writing with the future-web-language today!

Related Posts

1 comment

Powered by Blogger.