This looks very interesting indeed. I particularly like the fact that they're not trying to replace JS by using it as a compiler for a higher level language (as with Coffee Script, Dart etc.), and also I like how they've retrofitted the interfaces for the DOM, node.js, MongoDB etc. That's a nice touch.
The lambda syntax from C# is also nice to see, and something I miss when writing JS.
The difference is you can't use 3rd party libraries in CS or Dart unless you create some kind of wrapper for them.
TS allows you to use any JS library off the bat. If you want stronger type checking the you can define an interface to the library, but it's not necessary.
I think that's a much better place to be rather than create a whole new ecosystem.
But the opposite is not always true. There are many libraries written in CoffeeScript that are difficult to use in plain JavaScript due to the use of its class syntax. You can use Underscore.js to get around this, or just write your own inheritance code, but that's obviously a big tradeoff. Of course, using TypeScript libraries in JS will likely have this same issue.
there are many libraries written in JavaScript that are difficult to use in plain JavaScript due to the use of a classy syntax, that's why even halfway decent developers care about displaying clean interfaces / API endpoints.
Developers targeting the JavaScript community will be careful to have good API endpoints, but not all to-JS programmers care about that. Batman.js (http://batmanjs.org/) is one example that doesn't.
> There are many libraries written in CoffeeScript that are
> difficult to use in plain JavaScript due to the use of
> its class syntax.
No, there aren't. I can only name one, and it's a willful-on-their-part-oversight that could be easily fixed by adding a function like this:
Model.extend = (child) -> child extends Model
...
> You can use Underscore.js to get around this
No, you can't. Underscore.js has nothing to do with inheritance.
> Of course, using TypeScript libraries in JS will likely
> have this same issue.
Yep -- TypeScript implements a very similar inheritance function, and the potential workaround for subclassing TypeScript constructors from JavaScript should be equally easy.
The need for workarounds makes fragmentation an inevitability. That's not a reason for to-JS languages not to exist; every developer should make the decision on what works for their own needs, but ignoring it is foolish.
the 5ht sentence on the official coffee-script page[0] is: "It's just JavaScript", this sentence is not just marketing yadayada. everything that can be done in coffeescript, can be done in javascript, everything that can be done in javascript, can be done in coffeescript.
What happens when one of the APIs for node or Mongo adds a function? Would we have to wait for TypeScript to add the function to the interface, otherwise there will always be compilation errors? This sounds a little delicate.
Yeah, I agree with that, but when I upgrade Node I also don't want to spend an hour or two fixing out-of-date interface definitions (although that would be a great way to get familiarized with Node changes).
I suspect that if TypeScript takes off that this will probably be crowd sourced, i.e. expect to see a ts-node project on github.
That said, I think they've done a reasonably good job of making it painless. Even if it weren't required, I quite like the idea of explicitly listing the 'global' dependencies a particular script has. I think it's going to make unit testing it more pleasant, i.e. because you declare the dependencies your script has, it's obvious what you need to mock out from the environment to unit test it.
The interface just adds type annotations. You can still use APIs without type annotations, and untyped variables in Typescript itself if you want. It's not 'delicate' what so ever.
19 comments
[ 0.22 ms ] story [ 55.4 ms ] threadWe are a new startup working on making content more accessible through summaries, here is the HN discussion : http://news.ycombinator.com/item?id=4602377
The lambda syntax from C# is also nice to see, and something I miss when writing JS.
I think the solo presentation is better here: http://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-...
Dart is different, since it has a runtime.
TS allows you to use any JS library off the bat. If you want stronger type checking the you can define an interface to the library, but it's not necessary.
I think that's a much better place to be rather than create a whole new ecosystem.
yes, you can - i.e.:
[0] http://coffeescript.org/
I get it, thanks.
That said, I think they've done a reasonably good job of making it painless. Even if it weren't required, I quite like the idea of explicitly listing the 'global' dependencies a particular script has. I think it's going to make unit testing it more pleasant, i.e. because you declare the dependencies your script has, it's obvious what you need to mock out from the environment to unit test it.