The problem that TypeScript solves is that the web platform is in direct conflict with Microsoft's monopolies in PC gaming and business productivity software (Office). Confusing developers into thinking that JavaScript needs types leads them down the path of statically typed languages, i.e. C# and Microsoft's proprietary and closed .NET Framework and software ecosystem.
https://www.dartlang.org/articles/style-guide/#type-annotati...
Clojure? Scala?
Because instead of developing languages to run on top of them, people just designed languages to run on the same platform. The browser environment is a special case where the only common feature of the platform that is available to target is JS, there's no common VM underlying it, so replacements target JS.
Though its worth noting that while it may be true that no one developed a language to run on top of C++, C++ was originally implemented as a language that was preprocessed into C and then fed to a C compiler, much the way that many JS alternatives are compiled to JS and then fed to a JS interpreter.
- structural typing for interfaces (which means that classes implicitly implement an interface if the definitions match)
- gradual typing (mainly the ability to convert between 'any' and other types implicitly, which makes it much easier to interact with JS libraries/port JS code to Typescript.)
More generally speaking, Typescript aims to solve the problem of maintaining large codebases by giving you the additional security of static typing. The idea is that many simple errors can often be caught by a compiler, but would be much more time-consuming to find otherwise.
if (obj && obj.quack && typeof obj.quack == 'function') obj.quack(); //looks like a duck
- Refactoring e.g. easily globally change a class member's name
- Type safety e.g. it will bark if you pass a string where an int is expected
- General IDE handyness e.g. 'Go to definition'
A really good demo here: http://channel9.msdn.com/Events/Build/2013/3-314