Chris Price, October 2nd, 2012
What is it?
Announced yesterday, the official website describes TypeScript as -
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 -
|Compile-time type checking||✗||✗||✓||✓||✓|
|Run-time type checking||✗||✗||✓*4||✗||✓|
*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#.
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.
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.
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.
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.
This entry was posted on Tuesday, October 2nd, 2012 and is filed under Blog.