I ported a project to TypeScript last week, and was very impressed with the language. I had rejected it out of hand in favor of coffeescript, but didn't realize how modern and expressive a type system they had created. Bug-catching gains were immediate, and while it took a little bit to get comfortable with its ins and outs, I'm excited about coding everything in JS again.
100% agree. As much as I love CoffeeScript, the intellisense and type hinting is an invaluable aid to our team. TypeScript is the answer to team collaboration on large projects. There's no more guessing what the arguments are, whether an argument is an object or string. Source maps is icing on the cake.
I am impressed at how expressive interfaces and structural sub-typing are for Javascript, even though there is still no way to express a heterogeneous array. However, I have been very disappointed at how weak their type inference is and that they have no plans to improve it. http://typescript.codeplex.com/workitem/329
Heterogenous arrays can have very poor performance on some JavaScript VMs, particularly Google's V8. If you can avoid them in performance sensitive code, it's a good idea to do so.
You can't make the inference you suggest in the bug. It's not always valid. What if you set the variable in the function?
This line of type inference is very problematic in languages like JavaScript. Your statement that you expected "modern type inference" makes it sound like you only have practical knowledge (maybe you've used ML or Haskell?), not theoretical background. You should review the literature.
I just did a presentation on TypeScript last night and the biggest pushback was debugging in JavaScript. I told them source maps where coming, I had no idea it would be so soon though. Maybe next month we can have generics!
No GP but, personally I don't feel it's as good as the VS debugger. Unless I am missing something you still have to type into the console to get the value of things you want instead of just hovering over things, or bringing up quick watch in visual studio.
Also I'd imagine (haven't used it yet!) if you change the source in visual studio while debugging it would save to a file, while I cannot do that in chrome. I think I've heard it's possible in chrome, but never really seen how.
Chrome's debugger is darned near a full dev environment at this point, it's just not documented all that well and a lot of the best stuff has only been added recently. You can even edit the files, run the edited code, and save the changes locally.
You know what's really good about the Chrome debugger? It's free and it's on every computer that runs Chrome. Visual Studio is neither of those. I really wish they built VS functionality into the IE debugger.
As far as showing variables, one trick I use a lot is to set a conditional breakpoint where the code to execute is `console.log(stuff), false` so that it just logs stuff but doesn't ever stop. That's also handy for "fixing" variable values without stopping.
VS is free , well , at least the express version , which is more than enough for web development.
personally , I prefer to debug JS in VS than than in Chrome.
The chrome debugger never really worked well for me or did stuff as I would expect them.
Does it have conditional breakpoints and tracing breakpoints? I find the latter mostly entirely eliminate the need to sprinkle printf-equivalents to follow complex flows. For full disclosure I work on VS, but not the debugger or in Javascript, and I really don't know about Chrome's dev tools, but having seen some people's approaches to debugging JS, it feels like it is in a relatively primitive state from what I am used to in other languages.
I see conditional breakpoints, where are the tracing variety?
EDIT: Oh, I see, from your comment you are just leveraging the conditional breakpoint to ad-hoc them. That works but is a bit uglier than truly supported tracing breakpoints, and wouldn't appear to offer things like dumping the callstack to the output window or only triggering the print out only when specific conditions are met (i.e. a conditional tracing breakpoint). I suppose you could ad-hoc that as well by surrounding the print code with an if(<condition>) { print stuff }, <condition>. Works, hacky, but works I suppose.
Is there any concise typescript reference around? The playground doesn't showcase that much features. The language specification while extensive is not that great as a cheatsheet.