It seems to me that the type checking in TypeScript is extremely limited compared to what the Closure Compiler supports. The examples only show simple `fooInstance : Foo` examples, whereas Closure supports function prototype validation and such, a la C. I will need to see more elaborate examples.
Granted, there is no documentation that I could find on the website. I understand that this is a "preview," but I disagree with this way of presenting a tool. When the Closure Library was released, for instance, it was absolutely chock full of API documentation. This is because it was used for real-world projects and extensive docs mattered, even internal to Google.
There is a language specification (PDF, in the source tree) which is encouraging, but where's the manual? <http://www.floopsy.com/post/32453280184/w-t-f-m-write-the-fr.... The specification is largely a rewording of the ES5 spec with insertions where the typing additions are important. It will take a good bit for the reader to separate the wheat from the chaff, as they say.
I have more than a sneaking suspicion that this project is essentially a proof-of-concept, and that it is not heavily used at Microsoft. Do you remember "Microsoft Atlas" in 2006, at the height of the JS DOM Library Wars? In the end, they just pushed their developers to use jQuery with some code generation helpers. Microsoft's open-source track record for JavaScript is not impressive, and I think you'd be a damned fool to invest in this technology for any serious project.
I have more than a sneaking suspicion that this project is essentially a proof-of-concept, and that it is not heavily used at Microsoft.
My team has been dogfooding TypeScript for several months now, providing lots of feedback and writing > 30,000 lines of code (in many cases the new TypeScript code is shorter than the original Javascript).
In this case, I must infer that the culture of documentation is not the same at Microsoft as it is at Google.
Further, how can you have a tool like this and nothing for generating type-aware documentation from your source code? Google uses jsdoc-toolkit, so this is a moot point for them. Either you guys are using this in an informal fashion, or documentation isn't that important at Microsoft, or you just haven't released the doc generation tool(s), which would be a really odd choice!
Of course there is no API to document, and I noted the spec PDF in my top comment. Where is the manual, or something like one? At Microsoft, do they just tell a developer new to TypeScript to read the spec? Highly unlikely. MSDN is full of good documentation, and it's very weird that there's nothing of the sort for this project. I'd think that's an awful lot more important than Vim integration and such.
Even CoffeeScript had a manual very early on, and so did Dart.
I'm not saying "bad on Microsoft for releasing this!"; it's good they're starting to sort of figure out how open source works. Rather, like I said,
I think you'd be a damned fool to invest in this technology for any serious project.
Closure docs are pretty thin, mostly extracted symbols from code, with cryptic or misleading explanations. But a least you have clickable API listings.
I don't think this is fair at all. The Closure Library may have its dark and dusty corners, particularly for recently added/less used components, but on the whole, the library API is quite well-documented. You are mistaken about the API docs being generated from extracted code symbols; rather, it is all pulled from standard JSDoc tags. The library authors are meticulous about defining custom types rather than using ad-hoc enums and the like in their code, making the codebase itself very comfortable to reason about and making these @param and @return types very clear in their meaning.
I have my complaints about the library (certain dusty corners of goog.ui and goog.editor have hard-coded CSS classNames and Google URLs, meaning you have to use a patch queue to customize them) but I'm very pleased with the API documentation and examples. Google admittedly leans on Bolin's book (O'Reilly, 2010) too much for the community's manual-style documentation, but this is less crucial for a library than the API docs, and that book is really good :^)
The library has an extensive demo collection which is pretty nice too, and the demos generally include a minimum of 2-3 examples to show different ways to use library components (decorating vs. rendering usage of goog.ui package, for instance).
Google's real failure with Closure Tools has been marketing, but that is not my concern very much as a user. However, I see how this affects the library's adoption, so I've created a page at https://oinksoft.com/closure-tools/irc/ (I op the IRC channel) where I hope to aggregate more resources over time so that new users are able to get up-and-running without using Bolin's book.
It's an open-source iniative - great ideas like this are best seeded and grown through a great community effort. You sound like you want to be given the whole tree.
I'll grant you that; I expect a more impressive release from a company like Microsoft. Why is there so much work put into the website when the tool and its documentation are sorely lacking?
Granted, there is no documentation that I could find on the website. I understand that this is a "preview," but I disagree with this way of presenting a tool. When the Closure Library was released, for instance, it was absolutely chock full of API documentation. This is because it was used for real-world projects and extensive docs mattered, even internal to Google.
There is a language specification (PDF, in the source tree) which is encouraging, but where's the manual? <http://www.floopsy.com/post/32453280184/w-t-f-m-write-the-fr.... The specification is largely a rewording of the ES5 spec with insertions where the typing additions are important. It will take a good bit for the reader to separate the wheat from the chaff, as they say.
I have more than a sneaking suspicion that this project is essentially a proof-of-concept, and that it is not heavily used at Microsoft. Do you remember "Microsoft Atlas" in 2006, at the height of the JS DOM Library Wars? In the end, they just pushed their developers to use jQuery with some code generation helpers. Microsoft's open-source track record for JavaScript is not impressive, and I think you'd be a damned fool to invest in this technology for any serious project.