This is part 3 of 3 parts post. Part 1 is here, part 2 is here.
Because there is a compiler involved and because everyone out there is speeding up on comparing TypeScript to Dart, Clojure, C# and whatever there is I wanted to point out one thing very important that no one seem to notice:
Lots and lots of big products have been built with other tools of course and they work well too. The thing is that the tools were offered for free and almost no one put enough effort to figure out how and when should it be used. The developers were angry that they have to write their code following specific patterns and the learning curve for the components that were ready to use was huge. It still can be for new comers. The main complain was the style and lack of expressiveness because of the limited number of allowed patterns.
Strangely today the same developers are limited more than ever: most of the MVC frameworks are very opinionated about the code style and patterns that can be used, also most are not interchangeable, if you start with one product it is not such an easy task to switch to another, not really. So it is basically the same thing, I for example have never used AngularJS. Today I wanted to try to make something with it, well... I had 2 hours free time. Guess what - I could not complete anything in two hours. Maybe I am a slow learner, maybe it is not for me, whatever it is, the thing is you have to give it time.
If you have used closure tools before, TypeScript will be very refreshing and intuitive tool for you.
Yes, it does not provide the utilities closure has, yes, it cannot strip unused code, but it seems that the community is not interested in the later, even advanced projects like uglifyJS is not aiming to clear unused members because "it is not safe" for every type of code style. Yes, it is not. But is very beneficial. Anyways, unlimited by the patterns of closure library and compiler but still having static types and easy to follow annotations, having interfaces that can be checked at compile time, having sort of 'exports' (defined in the case of TypeScript) is very familiar to any closure developer.
Like in closure tools, you have to go through a build step before you can check your changes in the browser. In the case of closure tools, this is only when you change a namespace or require a new one, you need to recalculate the dependencies. In the case of TypeScript it is true even if you change a single letter, because the file that is loaded in the browser is not the one you are editing. I believe it will not take long for this to be overcomes like it was for closure with tools like closure-script and plovr.
Unlike closure the generated code is not obfuscated nor minified. However there are plenty of tools that will do that for you. Unfortunately the generated code is not compatible with the closure compiler in advanced mode and you will always need to load the full of your libraries if you happen to create them with TypeScript. The good news is that modern JS engines tend to not construct everything in the memory, there is something called lazy parsing, which I do not pretend to understand very well, but basically it says that if a part of your code is never used, it is never interpreted as well, except the first time when checking for code validity. Maybe this will solve some of the issues with downloading several megabytes of code and the caching will solve the rest? I have no idea, but the thing is that we see almost then megabytes of scripts being now part of a single application. The fact the developers tend to use patterns that are easy on the eyes and skills but hog on system memory is entirely different problem.
I find it easier to express complex constructs in TypeScript than in Closure, however the small number of people already interested in the language pointed out that it lacks some important types (for promises, deferred etc.) I believe those will be resolved in the next few months.
The language is still in Alpha! You have to know that. Also it tried to follow ES6, which probably means that if it changes the language might change as well. But it is a fun toy as well, especially if your mind set is polluted by the closure tools and you are constantly thinking about types and interfaces and static methods of classes.
So the verdict in my case (me being not really an acknowledged expert, but still with years of experience in large scale projects) is that TypeScript looks very promising and I will definitely enjoy working with it. Hopefully there will be a standard DOM library soon and hopefully widget library later as well. I also hope that it will be possible to construct a compiler that will be able to strip unused symbols to make it possible to developer large and well featured libraries without fighting for every byte.
A few words about the compiler and auto completion in other editors: last night post established that the completion and compilation can work entirely in the browser and this is true: open the play ground app and disconnect from the internet - everything will continue working: the completion service is available in the browser offline simply interpreting your code and using the main definition file (lib.d.ts). This really means it can be accomplished in IDEs like Cloud9 which already work in the browser anyway. Please please please do something about it, because I really don't like VisualStudio2012 and I dont even own a Window machine.