TypeScript is a recently released JavaScript superset which adds compile-time type-checking to the language, available with Intellisense as a VS2012 editor plugin and as a node.js command-line utility. That may be a mouthful but it's an exciting mouthful, let me explain why.

What is it?

Announced yesterday, the official website describes TypeScript as -

TypeScript is a language for application-scale JavaScript development.TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.Any browser. Any host. Any OS. Open Source.

Where does it stand?

If I were backed into a corner, after all we're almost comparing apples and oranges here, I'd probably come up with the following matrix -

*1 The code itself does not require compilation but the module dependencies may/may not depending on how you are using the library.*2 In the form of Intellisense (other brands are available) which works but certainly not as reliably as other languages e.g. C#.*3 Again only in the form of Intellisense (other brands are available), I don't know of any IDE which makes use of the type information nor is able to hint when adding the type information. As John points out in the comments, WebStorm now supports most of the Closure syntax.*4 Again as John points out in the comments, it is possible to have the compiler insert runtime type assertions by enabling the runtimeTypeCheck flag on CompilerOptions.

From the matrix you can see for me that TypeScript lands roughly somewhere between Closure and Dart. Where exactly between these two is much harder to say. Personally I see it more as a modernisation of Closure rather than a cut-down Dart as it has been described elsewhere.

Why do we need it?

Closure has some great features but as with most things that have been around for a while, it's structure is now more a product of evolution than design.The benefit TypeScript has in starting from scratch is that the best features can be kept and enhanced, while the legacy features can be dropped without fear of breaking anything.

A good example of this is how each toolkit approaches dependency management. Closure is built around the functions require/provide and a bunch of Python scripts (or Plovr). Whereas, TypeScript has module/import baked into the language which can output either AMD and CommonJS compatible modules. This isn't a bash at Closure it has a very good reason for it's approach, it pre-dates both CommonJS and AMD by a good number of years, but does show the advantages of starting from scratch.

One big frustration with Closure though was the lack of IDE integration, going to the effort of adding and maintaining huge swathes of JSDoc comments but not having your editor able to make any use of them felt like such a waste. There are various hints in the compiler source code that someone has at some point played around with the idea, but sadly it has never seen the light of day.

Another frustration came about when trying to migrate an existing codebase to Closure. The compiler has two modes, simple which provides no type checking but imposes no constraints on your JavaScript and advanced which does the opposite. The big advantage of starting to use the compiler is being able to static type check your code however, because of the constraints imposed on the code by advanced mode, you need to invest a lot of effort to JSDoc-ify your code up front before you can get any benefit. There simply isn't an easy way to transition to using the compiler.

As pointed out by Fredrik in the comments below, both the simple and advanced modes of the compiler do support type checking if you bump the warning level up to verbose. Advanced mode does still require extensive JSDoc but is only required if you want the more aggressive renaming, dead-code elimination and global inlining.

I think Closure is a great toolkit but it hasn't really hit the mainstream so why should TypeScript? I believe these issues had a lot to do with Closure's poor adoption and I'm happy to see that TypeScript doesn't suffer from these issues, it already has the IDE integration, and being a superset of JavaScript migration should be much easier.

What is it like?

My first impressions are pretty positive -

• The module pattern works well both inside Visual Studio for Intellisense but also from the command line when compiling the modules into either AMD or CommonJS format.
• The types syntax feels quite natural and is supported by Intellisense. Implicit typing also seems to do a decent job.
• Declaring external types e.g. from libraries is currently relatively painless but laborious. I'm sure a repository of declarations for common libraries will turn up soon. However, it is unfortunate that the only way of referencing external libraries is to fall back to the VSDoc reference pattern.
• Renaming properties using the refactor option in VS works perfectly, as does the Find All References command. On a large codebase these features could make a huge difference.

It's not all positive though, there are a few rough edges both to the plugin and the language itself. E.g. the code comprehension seems a bit slow, the completion doesn't work quite as expected and supplementing interfaces doesn't seem to work as described. However, for something that launched yesterday I'm willing to give it the benefit of the doubt.

Conclusion

As great as it is to see a project like this, and as much as it has already achieved, I think it's worth holding back from using it just yet. Things seem a little bit unpolished and the specification document still has a few holes to be filled. I'm sure these issues will be fixed soon though, so I'll definitely be keeping my eye on it.

Tweet