This project is read-only.

Who here is using TypeScript for a critical App right now?

Topics: General
Dec 6, 2012 at 8:41 PM

Hi All,

Just curious who here is using TypeScript to build an important app right now?

I converted one of our new apps over to TypeScript.  It's a single page app that was written using backbone.js.  So far I'm happy with the move but there are debugging issues that are really making me cringe at the moment (e.g. after refreshing a page in IE the breakpoints no longer hit in .ts files).

Is anybody here using this for critical apps? What are your thoughts so far? Is it making you more productive/better able to write better apps faster?



Dec 8, 2012 at 2:24 AM
Edited Dec 8, 2012 at 2:26 AM

Jon, our site was completely re-written in TypeScript (30,000+ lines of TypeScript.)  We're still debugging against the generated JavaScript files so I haven't had too much of a chance to work with the new debugging support but looking forward to it now that we've shipped :)  I can tell you that while the tooling may still have a few kinks the compiler generates valid JavaScript so in our opinion it's better then working in JavaScript directly.  I can pretty much guarantee you that for any project of significant size, TypeScript WILL catch bugs in your code.  

Dec 10, 2012 at 1:04 PM

About 3000 lines or so to date. Most of the code is in the XML -> model parsing. Sadly. Typescript catches lots of errors regularly - specially those spesky parseInt()s :) 

Dec 10, 2012 at 2:25 PM

Awesome feedback!  You both have done some significant .ts work! 

Makes me feel better that there are others vested in it with important projects!

I know the team working on this are superstars, I'm just anxious for the last pieces of tooling to come together to make a great productive dev workflow!


Dec 10, 2012 at 9:54 PM

I'm rewriting the Alanta client from Silverlight to TypeScript. I'm about 3000 lines into it so far (the Silverlight version is about 30,000), and have found a number of bugs in the TypeScript implementation, and probably even more in the spec (IMO), but I'm still dramatically more productive with TypeScript than JavaScript. It has some features that would be nice in C# (such as duck typing), but on the whole it's not quite up to C#: I'm missing generics especially, though I know they're coming. But I don't regret my decision to jump into TypeScript in the slightest: for all of its rough edges, it's still much better than JavaScript.

Dec 11, 2012 at 8:56 AM


The team I'm on uses TypeScript for a critical proprietary app. It has made development way faster and far more robust; especially when time comes to refactor. The compiler really helps catch a lot of those little slip ups that happen when we get tired. It also allows for people coming from other languages to bring more language agnostic skills to the table. TypeScript is also easier for people to transition to if they have had prior experience with ActionScript 3, Java, or other more traditional OO-paradigm languages.

To support the TypeScript, we use Jasmine for our tests. For the CI we use Jenkins with Gradle for build automation. We also run the Jasmine tests through PhantomJS. If you are interested, I created a TypeScript CI starter project on GitHub based on what we use. You can find it here: 

The project is not complete or ideal, but it is functioning for us right now. When I have a chance, I'll go back and add code coverage and such.

Most of our people work on Mac or Linux, so I haven't had a chance to test Gradle running PhantomJS running through Windows yet. If it causes you any problems, just let me know; or even better, fork and send a pull request. 

Dec 11, 2012 at 2:33 PM
Edited Dec 11, 2012 at 2:33 PM

Wow you guys are all slaying it with TypeScript!  I'm also surprised with how much traction it is getting outside of the MS world.

For example quite a few Typescript support requests for JetBrains (makers of resharper) seem to be from people outside of the VS world.

A common thread here seems that nobody (or very few of you) are debugging the raw .ts via Visual Studio unless I'm wrong with that.

That's the workflow I'm going to switch to until the .ts debugging gets better.  

  • Code .ts files in Visual Studio for the intellisense
  • If VS starts to freeze while coding .ts (which happens in some scenarios) use sublime text to edit the offending file and get it to build (using the syntax highlighting and build system for sublime text)
  • Debug raw .js with Visual Studio's .js debugger

At least I will never be stuck with that setup!

Cheers to all and keep slaying it!


Dec 11, 2012 at 2:56 PM

Surprisingly the debugging support for ts in Visual Studio is very good, more friction-less than debugging ts files in Chrome.

There is only one annoying thing: that refreshing the browser will ruin your debug session. (IE)

Dec 11, 2012 at 3:50 PM

Yeah, debugging in TS is still pretty buggy, though very helpful when it works. I run similar problems woth with Visual Studio and with Chrome, with breakpoints not getting hit, that sort of thing. My suspicion is that there's a bug in the source map file generation. I've finally turned off SourceMap debugging in Chrome, so that I can have a reliable debug experience somewhere, though I usually do my first pass at debugging in Visual Studio with the actual TS files.

Dec 11, 2012 at 4:20 PM

Personally, I am a big Sublime Text fan for web development. My preference is mostly due to the speed and customization of the editor. However, in the case of TypeScript I end up debugging in Chrome anyhow if I want to easily debug my Jasmine unit tests. Perhaps I'm just not doing something right, but that TS <--> JS switch doesn't seem very seamless when I debug the TypeScript through VS right now. If VS had more of a seamless solution for switching between my JS unit tests and TS then I would probably change my opinion. However, for now I've ended up just using a build-on-save plugin with a TS build system in Sublime Text (debugging in Chrome).

All of that said, the rest of the team generally just use VS (Through Parallels or VirtualBox on Mac and Linux).

Dec 11, 2012 at 8:10 PM

If you don't have VS for editing, or if you prefer some other editor, you may be able to add support for type hints, jump to definition, and completion to your editor.

There is a commandline server interface (commands in, json info out) to the TypeScript language services here:

It comes with a basic Vim plugin, offering the services above on top of the syntax highlighting provided by the TypeScript project. Someone was working on an Emacs plugin (, and if your editor is programmable/extensible and can communicate with an asynchronous subprocess, you might be able to write a TS plugin for your favourite editor. It is still work in progress, but I would like to stabilize the basic protocol soon, so it would be good to know if the present form serves the needs of other editor plugin writers.

Dec 11, 2012 at 9:27 PM
Edited Dec 12, 2012 at 1:54 PM

If the key *value proposition* of TypeScript is to make developers more productive (that's what Anders said his focus was on Hanselminutes)...

I think the TypeScript team is best to focus on getting this workflow stuff figured out before any other features (e.g. generics).

It seems that there is a lot variation here on how we are all trying to get our work done.  It's great that there is choice (different editors, etc), but there should be at least one setup that seamlessly works for coding and debugging TypeScript.  

Nailing this story down first is the most important to me.

EDIT: Just want to add, that the above is a prioritization thought by me.  I understand that we are using Alpha software... Typescript promises to be one of the best productivity enhancements for us very soon, and I really appreciate the efforts of the great team working on this!