7 Months With Type Script

Posted on

Since December 2012, I have used TypeScript as my primary language while working on a large scale enterprise project due to ship next month. I want to share the details on how we are using TypeScript as a team and our workflow that has made our project a success.
TypeScript is an open source language and compiler written by Microsoft that runs on NodeJS. The language is based on the evolving ES6 spec but adds support for types, interfaces that generates JavaScript (ES3 or ES5 dialects based on flag). TypeScripts compiler is written in TypeScript and run on any compliant JavaScript runtime by default it is distributed as an npm on Nodejs. End of the day, JavaScript is generating JavaScript

In November 2012, we selected technologies and our initial evaluation of TypeScript proved surprisingly beneficial. While we evaluated Haxe, Dart, CoffeeScript, we quickly honed in on TypeScript given it is an ES6+ to JavaScript compiler. We wanted all code to be JavaScript but we wanted to inject structure into our development process and be able to lean on the compiler for validation and richer errors. Really our choice boiled down to either use JavaScript or TypeScript. From there we wrote several small scale prototypes and quickly exposed the following

Validation TypeScript enabled us to validate code usage cross-modules at compile-time. In assigning types to variables and to method arguments, we were able to effectively validate all call/get/set across every module, every build. If a property was set to type bbox.controls.Image, nothing would satisfy the compiler but an Image instance or a subclass.
Early errors We would get very detailed errors from the TypeScript compiler and with the addition of types and interfaces, the errors got even more specific.
Zero calorie types TypeScripts types and interfaces evaporate at compile time leaving no trace of the language while generating clean JavaScript.
ES6 Today TypeScript is based on ES6 with additions of types and interfaces. It let us write source in a modern dialect of JavaScript, yet output to compatible ES3, ES5 with a compiler flag. With support for a modern class syntax( constructor, subclassing, interfaces, export, modules ) it made code organization painless.
Build process One of the first checkins and tests was to create a team build process with Ant. With a properly configured environment any developer could sync with SCM and build a working local server with all code packaged for development or production use. The build process integrates Less, RequireJS, Uglify2, TypeScript, template processing, and server generation.


In the months that followed our evaluation we settled into a team workflow with TypeScript that really benefited our project. The build process is at the center of development and our daily work. Every day looked like so:

  • Update from SCM
  • Run ant all ==> Full build + start local server
  • Run ant dev or ant ts ==> Incremental build
  • Error at build or Test in Browser
  • Rinse & Repeat


I really enjoyed this model in that I found over time that we spent far less time in the browser testing than prior JavaScript projects. As the build would validate and catch syntax/interface/type/usage errors, we only browser tested when the build validated and worked. Once we all got better at decoding the TypeScript compiler output errors, we gained a level of productivity that I have not encountered in web development. It sounds odd to spend 5 seconds compiling but in the end it removed an entire class of useless testing of non-working code from our development schedule. This aspect alone saved us 2 months of time while dramatically improving the output code quality.

When we began development the quality and quantity of available TypeScript definition files was not ideal. Definitions allow you to strongly type the interface of JavaScript Libraries externally and thus your code must conform to the definition at compile-time. Since starting this project definitions have done a complete 180 with many contributions to Definitely Typed for just about any major or minor JavaScript library in existence. We utilized the definition files for Require, JQuery, Backbone, Bootstrap, Underscore, and EaselJS within the build process. To add a definition file you simply add the following reference statements to the file within your main .ts file:


The references above are also how you add in any external libraries to TypeScript. In a way definitions, interfaces, and TypeScript classes all operate in the same way. In order to simplify our build process we unified all these calls in a single init.ts file which when called by the compiler loads in all TypeScript needed by the application. Even classes that are intended to be loaded via module are denoted here so that they are externally compiled to a module file. Note the use of the export Class syntax in this external module, this tells the compiler to keep the file external as a module and a compiler flag module amd makes the compiler format modules to conform to either AMD or CommonJS format.


Another elegant item is the module system in TypeScript for code organization. Each class and variable is exported into a path off the browsers window object making it global. We utilized the namespace bbox for all classes and variables and with typing support, you can make a very well defined namespace for your application quickly. The module above starts in bbox.controls and at runtime you can find this class exported to bbox.controls.Bounds. Considering we have 60+ classes to work with we used the module system to its limit and it never missed a step. You are free to export and type individual variables and whole classes this way so you are not locked into everything needing to be a class. In many ways a typed export variable works great for singletons within a module as it provide limits to the type written and location accessed. With the additions of modules and types, the way you work with JavaScript just changes and it is a blurry line what is considered bad practice. With a first class compiler that can detect overwriting an object with an array or a very specific class type, you begin to work differently as TypeScript induces its own working model as a language. It isnt JavaScript, yet it is.

Over the course of development I found myself changing development strategies in terms of refactoring. I started to trust the compilers behavior to the point where I would intentionally change types, interfaces, and naming to break things in order to expose code affected. I would then correct all lines from the compiler output and refactor as needed. In many ways this has allowed me to work effectively within a larger codebase.


As for development environment, I went with Sublime Text 2 + TypeScript syntax, while the other developers on the team opted for JetBrains. I found Sublime to be a great environment for TypeScript, even without code completion, I had zero complaints. Given that the compiler can provide incremental compilation and richer ide integration I think it will be a matter of time before we see far more advanced TypeScript tooling in Sublime/Edge/Jetbrains offerings.

While I loved working with TypeScript (and will continue to do so) there is one escape hatch that every developer using it should understand. There are times when you will butt heads with the compiler and it will block your attempts to call a method or variable as typing information is unavailable. When this shows up, we found that associative array syntax would unblock the issue til we could fix thing up. Example: foo[myProperty] foo[myMethod]() would allow you to access myProperty or myMethod on foo regardless of typing information. I know it sounds odd but just keep associative array syntax in your back pocket, you will need at some point.

Some project stats on the project:

  • 63 TypeScript Classes
  • 12 libs ( Underscore,Require , Bootstrap , Jquery , Backbone , EaselJS )
  • All Build 8 seconds
  • Dev build 5 seconds
  • 149Kb Libs & 411Kb Classes
  • Summary

TypeScript has been a joy to work with over the past 7 months. Having had experience with types/interfaces in ActionScript/ES4, I took to TypeScript very rapidly as it supported the structure I needed, yet maintained the elegant flexibility of JavaScript. In many ways I know our choice in using the compiler really moved our project forward in both delivery date and in code quality. I cannot say I have ever been a Microsoft fan but TypeScript has softened me, it is easily one of the best web technologies to arrive in the past 3 years. I am looking forward to working on more projects with it and evolving with the language/compiler ongoing.