All of these blog posts about Typescript are a waste of space. All we've seen are visceral reactions and observations with toy problems.
If you try to use it for a real application, you see three things:
1) Typescript tries to change certain javascript idioms. For example, the first thing I do when writing a node module is the commonjs module interface, which is not what TS wants you to do. A common source of criticism is the fact that the typescript pattern doesnt match all of your idioms, which is fair but shouldn't be a reason to immediately throw it out
2) There are some places which break javascript. For example, parseInt(0.3) is an acceptable javascript call, and it is acceptable according to the spec, but typescript requires that a string be passed as the first argument. Again, it's nascent and hopefully those quirks will be fixed.
3) If you are even remotely professional about your development, the type hints have little value. You already keep a careful map of the code in your head, and you are careful not to make the mistakes that typescript would catch.
I would disagree with item 3. I am a professional developer. Not remotely professional, but flat-out professional. And I make mistakes. I know other developers, wait, greater than remotely professional developers, that also make mistakes. Even though I'm a professional developer and I've got a careful map of the code in my head, and I'm careful not to make mistakes, I still make mistakes. I've seen other developers do the same thing - make mistakes. I'm always stunned, but it keeps happening. I have found that type hints, code completion, intellisense, helps me discover mistakes sooner, often before I make them. I have found that mistakes found sooner are cheaper to fix. Type hints have huge value for productivity. Often, BTW, you are using a class (or JS function, whatever) that you didn't write, so you don't necessarily have this careful map in your head, your trying to figure out what this beast is that you're using, and hints are extremely helpful there.
I think Typescript is great, from what I see so far. And it's not like Anders is trying to hijack JS. I see it as a development tool. If the next guy doesn't want to use TypeScript, fine, have at the JS, it's nice code that it produces.
There's a really interesting documentary about Edsger Dijkstra in which they looked back at his old notebooks. He wrote by hand, and when a correction was needed he'd tape a segment on top of it, and sometimes youd see stacks of these corrections. When all of the fragments were removed, the top version almost always was same as the original.
The point of the anecdote is that most professional developers I've met are incredibly disciplined and take time to understand the intricacies of what they are working with before starting. The types of mistakes that Typescript can catch stem either from carelessness (like mistyping) or memory loss (forgetting a function signature), but those can be obviated.
"I have found that type hints, code completion, intellisense, helps me discover mistakes sooner, often before I make them"
Code completion shields you from spelling mistakes. Intellisense saves you the need to remember the signature of various functions (most of which you should know anyway). Type hints help with nondescript names, but hopefully your variable names have the types implicitly embedded (e.g. 'count' or 'cnt' are almost always integer types)
I'm not saying most people don't suffer from these problems from time to time, but most professional developers I know are very careful and write good code the first time.
"Often, BTW, you are using a class (or JS function, whatever) that you didn't write"
Again, most APIs use sufficiently descriptive names that there should be little confusion. If there is ever a point where something is not clear from the outside, oftentimes there are issues on the inside that should be addressed (minimization notwithstanding).
I think Typescript misses the point. A high quality linter for javascript could pick up on most of the issues that TS picks up on. Furthermore, there are some quirks that break compatibility, which does to an extent suggest hijacking.
However, when working with good type inference (i.e. Haskell)... 1: it's possible to relax on the discipline a little; mental resources are limited (at least for me). 2: typed-based dispatch; refactoring based on static types; etc.
I think you're misremembering the documentary. It was Dijkstra himself reminiscing about a composer, whose scores had corrections taped over them. He was illustrating the difference in mindset by comparing Mozart to Beethoven.
Static types are attractive to me. I haven't tried Typescript for other reasons:
1) I use CoffeeScript for the concise code, which Typescript doesn't have. The trade is a lot of verbosity for static types - verbosity above the static type declarations.
2) I don't know much about Typescript's type inference system, especially how it will develop. Not well documented, no vision. (Clojure's vision is one that I would consider exemplar.)
3) Suppose there are cases where Typescript is more appropriate. I don't know whether it is easy to expose functions to normal Javascript (while retaining types). Typed subsets of a language have often been problematic to expose to untyped parts of a language when more powerful inferences are being used (e.g. Typed Racket doesn't play well with Racket Macros). Especially if you want to pass typed => untyped => typed.
4) There's a cost to learning a new language. There's an overhead to remember an additional language.
5) Chances are, someone else is going to try it. Someone who actually has a good use case. If I wait, maybe they will talk/blog about it, and I can make a more informed decision later.
I haven't been persuaded to try Typescript in a substantial piece of code. The blog posts, they don't really address the issues of concern to me. Not yet.
If you try to use it for a real application, you see three things:
1) Typescript tries to change certain javascript idioms. For example, the first thing I do when writing a node module is the commonjs module interface, which is not what TS wants you to do. A common source of criticism is the fact that the typescript pattern doesnt match all of your idioms, which is fair but shouldn't be a reason to immediately throw it out
2) There are some places which break javascript. For example, parseInt(0.3) is an acceptable javascript call, and it is acceptable according to the spec, but typescript requires that a string be passed as the first argument. Again, it's nascent and hopefully those quirks will be fixed.
3) If you are even remotely professional about your development, the type hints have little value. You already keep a careful map of the code in your head, and you are careful not to make the mistakes that typescript would catch.