I don't know very much about TypeScript, yet, but I'm doing some research and I'm going to advocate it on my next project. From what I already know:
> Not having to constantly keep adding types all over,
TypeScript is gradually typed (which means it's happy with as little or as much type declarations as you want to give to it) and uses type inference, which reduces amount of needless type declarations even more. Actually, coming from C and later C++ to Python and JavaScript I thought the same as you, that type systems are a complete PITA. I then learned OCaml and I changed my mind: bad, archaic type systems are PITA, but modern and powerful ones are a huge help and incur little cost.
> and retains purity of JavaScript
That's like saying that you're not using any Scheme library which implements convenient exception handling and you use bare call/cc instead.
Prototypal inheritance in JavaScript is strictly more powerful than most of the class based systems, but it is less convenient to express some common idioms using just what's built-in. This is why you're going to implement some kind of object and meta-object protocols on top of prototypes sooner or later. It makes sense to agree on a standard way to do it, otherwise you're just going to add yet another slightly incompatible object system. I agree that there are many cases where prototypal inheritance is enough, though, and you shouldn't use classes by default in JavaScript.
> adding types all over and maintaining them over the evolution of code is actually higher
I have vastly different experience here. Types tend to make refactoring rather easier than harder. It's because when you change a return value or expected argument of some function you don't need to grep for all its calls in the codebase - the compiler will tell you. With sufficiently good type system, the compiler will tell you if the new type is compatible with the old one, which makes writing adapters easier. And it all happens on compile time, which means you don't need to run your app to test it. I read that TypeScript compilation is slow - that may be, but I bet it's comparable to running all the unit tests for a project, for example.
> It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension.
Yeah, I agree, I'd like it too. I remember there being a very cool project from some distinguished JS developer which did just that; it was an editor and a supporting library for checking and validating JS code. I can't remember what it was, exactly, though... Help, anyone?
> Just because JS doesn't have type checking
As I said, it's not either-or situation. Gradual typing is one thing, contracts are the other. You can have the best of both worlds. After a few years I'm still amazed with Racket and Typed Racket combo - it's exactly the right mixture of compile-time and run-time support for ensuring program correctness and I would like to have something very similar in JS one day. In the meantime, TypeScript is a step in the right direction. I only hope it will continue to evolve after 1.0 release.
I have performed QA tasks on both, and find that either JS developers are better or going pure vanilla makes a much stabler product. The TypeScript projects I have seen had some major flaws and requests (vs bugs) always turned into low priority because of the inability to perform the task.
I think it's easy to explain: TypeScript is a new technology and programmers will have very little experience in using it. It's completely impossible to find "TypeScript programmer with 5 years of experience" for example. On the other hand, JS is stable and much older and you can easily assemble a team of highly experienced people.
Relative strengths and weaknesses of TypeScript will be only visible after it's around long enough to get its own best practices and experienced programmers. I see the same process with CoffeeScript - in the beginning average CS code was much worse than average JS, but now they are comparable and the advantages of CS are starting to be visible.
That's of course on average. It's still possible to get a few people with enough knowledge to be able to use TS effectively, but I think it's hard enough to make it very rare. It's unfortunate, but technologies - and especially languages - take very long time to mature. In short, your impression is probably correct, but it's not because of TypeScript features; we need to wait a few years before we can compare TS and JS products success rates.
> Not having to constantly keep adding types all over,
TypeScript is gradually typed (which means it's happy with as little or as much type declarations as you want to give to it) and uses type inference, which reduces amount of needless type declarations even more. Actually, coming from C and later C++ to Python and JavaScript I thought the same as you, that type systems are a complete PITA. I then learned OCaml and I changed my mind: bad, archaic type systems are PITA, but modern and powerful ones are a huge help and incur little cost.
> and retains purity of JavaScript
That's like saying that you're not using any Scheme library which implements convenient exception handling and you use bare call/cc instead.
Prototypal inheritance in JavaScript is strictly more powerful than most of the class based systems, but it is less convenient to express some common idioms using just what's built-in. This is why you're going to implement some kind of object and meta-object protocols on top of prototypes sooner or later. It makes sense to agree on a standard way to do it, otherwise you're just going to add yet another slightly incompatible object system. I agree that there are many cases where prototypal inheritance is enough, though, and you shouldn't use classes by default in JavaScript.
> adding types all over and maintaining them over the evolution of code is actually higher
I have vastly different experience here. Types tend to make refactoring rather easier than harder. It's because when you change a return value or expected argument of some function you don't need to grep for all its calls in the codebase - the compiler will tell you. With sufficiently good type system, the compiler will tell you if the new type is compatible with the old one, which makes writing adapters easier. And it all happens on compile time, which means you don't need to run your app to test it. I read that TypeScript compilation is slow - that may be, but I bet it's comparable to running all the unit tests for a project, for example.
> It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension.
Yeah, I agree, I'd like it too. I remember there being a very cool project from some distinguished JS developer which did just that; it was an editor and a supporting library for checking and validating JS code. I can't remember what it was, exactly, though... Help, anyone?
> Just because JS doesn't have type checking
As I said, it's not either-or situation. Gradual typing is one thing, contracts are the other. You can have the best of both worlds. After a few years I'm still amazed with Racket and Typed Racket combo - it's exactly the right mixture of compile-time and run-time support for ensuring program correctness and I would like to have something very similar in JS one day. In the meantime, TypeScript is a step in the right direction. I only hope it will continue to evolve after 1.0 release.