Looks to me like it’s a statically-typed, class-based language that compiles down to JavaScript. It’s a good idea, and one that others have had as well.

The advantages should be obvious to anyone who’s developed in both statically-typed, class-based languages and in JavaScript:

• First and foremost, a compiler. Being able to check for obvious correctness problems caused by typos or carelessness prior to deployment is something that most developers take for granted until they have to do web development, and then it’s suddenly yanked out from under their feet. Browsers are designed to make the browsing experience pleasant at the expense of proper testing and debugging facilities, and the standard solution, JSLint, is no substitute for a real compiler as it misses some obvious correctness problems and mixes a bunch of style-checker complaints in with its reports. Having a real compiler is a huge step forward.
• And along similar lines, a type system. Type systems improve your code by making it easier to read (you know exactly what’s being passed into a function, and what it can do, just by looking at the parameter list, for example,) and by enforcing a certain degree of correctness at compile time. (If you’re expecting a specific object type, passing an integer is an error. JavaScript will let you do that and then it blows up when you try to run it; a compiler with a type system will catch it and report an error for you.)

So as we see, the basic idea is a very good one. Having said that, I can’t say anything about the language itself because I have no experience with it. But I’ve used Smart (linked to above) and found it to be an incredibly powerful and useful tool for web development.

There are a few good reasons to use TypeScript, as far as I can see. First and foremost, as Mason Wheeler said, a compiler. Or rather all the checking a compiler does. JSLint and other tools are useful, but misses some problems and are sometimes plain wrong. I certainly welcome this “innovation”.

Then there is a real type system, improving readability and enforce correct types. After all, this increases development speed.

For me, one of the great things is tooling support. That’s probably a side effect of the type system, but nevertheless great. And really necessary, as current JavaScript tooling-support is beyond useful.

TypeScript tries to extend JavaScript. The compiler generates really nice JavaScript. And in addition to this, it follows the ECMAScript 6 proposals. (For example arrow function syntax, parameter default values, modules and so on.

It makes working with modules and classes easier. It is actually possible and quite common to work with classes and modules in JavaScript, but it requires some amount of boilerplate code. And it is not really easy to be read. TypeScript allows to write class-, interface-, and module-statements just like in Java or C#, which is by far easier if you ask me.

But after all, it is still just JavaScript. There is no need to learn a new language, or syntax. The only thing it adds, is the optional type system (which is great and overdue).

Then there is the “definitions library”, which means I can use all my JavaScript libs without rewriting, or even patching them. However, I have the additional type system now.

I will definitely give it a try!

One last things, there is no competition between HTML5 and TypeScript. But that’s another story.

We had JavaScript, then we had Flash, then we had Silverlight and then HTML5 ownd them all.

This is simply NOT true. Html5 does not own them, it introduces new markups that simplify usage of multimedia, and explores advantages of new era browsers (like using hardware acceleration while rendering html).

So what is the motivation behind TypeScript?

Motivations might be driven by reasons to use it. All features of TypeScript like : static checking, symbol-based navigation, statement completion, and code refactoring are very strong reasons to consider it.

In addition, it offers classes, modules, and interfaces to help you build robust components. These features are available at development time for high-confidence application development, but are compiled into simple JavaScript.

It may be treated as a tool to manage javascript development rather than a total new language that compiles to JS. It do not want to be a server side development language like Dart, and not have a different syntax like CoffeeScript. It did not want to take a popular language(and it’s core library) and compile it to JS like GWT or script#. TypeScript even follow same “class” syntax proposed for next version of JS.

I think most of the web development is done today uses real javascript, in the client side only. Languages or frameworks like Dart, GWT is not suitable for this. If you go for coffeescript, a new syntax comes up. And you have to understand both coffeescript and JS. While TypeScript is just adding a few extra type oriented features, melded into JS, which save developers from type-specific errors(which is a large portion of JS errors) and gives the development tools more information about developers intent.

This approach is not new. Go to the “Static Typing” section of

This article address your query- http://www.eweek.com/developer/microsoft-delivers-typescript-a-better-javascript-for-big-apps/

I think it’s a effort to turn a shared, unreliable piece of crap (javascript) into a proprietary language that can actually be used for substantial projects.

It ought to be compared to GWT, which has a similar set of goals but took a cleaner approach by making javascript not part of the language; and with Java applets or Flash, which take the very clean approach of defining a complete runtime environment independent of the browser.

Your opinion may vary, but I think it’s doomed as long as it depends on the browsers
natively supplying the (varying, inconsistent) javascript implementations and DOM models.