Lambda the Ultimate

If Dart was a superset of JavaScript ad supported existing JavaScript libraries, us, but dart doesn't...these languages are targeting completely different things. Typescript seems to be more like coffee script with more static typing.

I agree the form is very different, and being easily compatible with Javascript is surely a major advantage of Typescript in terms of adoption potential (and also a relative downside in terms of which semantics aberration it will protect us from).

Yet I think it's fair to say that they have the same purpose: making "large-scale" programming possible in client/server Web scripting languages. From that I disagree with your assertion that they "are targeting completely different things".

My own prediction would be that Typescript is in position to completely obsolete Dart at this point (again a sign that they play in the same playground, rather than being orthogonal in purposes). I have mixed feelings about this, because I have both deep disagreements with Dart technical choices and deep respect for Dart design team and their choices, and because I feel that if Dart is to fail it will also be for "political reasons" (Mozilla and Webkit refusing to consider Dart at all) that are not as noble as technical considerations. Finally, TypeScript is yet another occasion to make (well-deserved) good publicity for Microsoft proprietary IDE toolchain, which creates cognitive dissonances between my programming language interests and strong support of free software.

So far, it seems that Dart focuses on performances, while TypeScript focuses on convenience and tooling for large-scale project (while in fact both can win on both sides). It will be interesting to see how people choose their camp.

One last remark: to improve performance, TypeScript implementors will have interest in adding enough low-level typing features to Javascript for it to become a better compiler target (through the ability to express stronger representation invariants). That's good for everyone. Dart-to-javascript has the same incentives, but Dart was also a move away, by a part of Google, from the trend to improve Javascript.

I'll give you that they are probably going after the same cake, but the design approaches are completely different. Dart is a new language, typescript is more of a C++ move by taking a loved language and giving it more love in a backward/forward compatible way.

Visual studio isn't the end of the world for IDEs languages. We just need to get more busier at reinventing the language interface (i.e., go beyond smalltalk). from this perspective, typescript is boring, but so is its competition. At least we get intellisense, howver.

TypeScript is an optionally-typed, design time, syntactic layer over plain old JavaScript, providing classes, interfaces, modules for use in structuring large JS code bases.

Dart is Dart. It can compile to JS out of convenience (for obviously pragmatic reasons...), but it doesn't have to (and, really, it's best to take full advantage of the Dart VM, anyway, not JS engines, especially if you want to, say, write Dart applications...).

Regarding IDE adoption, it's still pretty early, but Cloud9 implemented TypeScript support for their browser-based IDE in a few hours. Nothing prevents more industrial strength IDEs (a la Eclipse) from doing the same over time. Even without an IDE, TypeScript is still useful.

I'll give you that they are probably going after the same cake, but the design approaches are completely different. Dart is a new language, typescript is more of a C++ move by taking a loved language and giving it more love in a backward/forward compatible way.

I suppose my phrasing wasn't clear about whether I was asking about the cake aspect or the design aspect. You've answered both, so thanks!

Since large-scale JavaScript development is squarely in the dark ages, moving to the middle ages is a good thing :-)

The TypeScript playground already has code completion support in pure JavaScript, so I can't imagine that functionality won't rapidly spread into IDEs other than Visual Studio.

The interesting question is whether TypeScript addresses enough of the needs of large JavaScript developers to pull momentum away from Dart. Dart has a number of technical hurdles in the way of wide usage on the Web. TypeScript has none whatsoever since it is really just JavaScript. I'm frankly surprised Google went with a bet on a new VM and whole new language in the first place; I would have expected them to get behind ES6 and go in a more TypeScript-like direction. TypeScript seems to be getting rapid uptake already, and if it covers the 80% cases well, it's not clear how much rationale Dart is left with.

(Disclaimer: I work for Microsoft.)

Since large-scale JavaScript development is squarely in the dark ages, moving to the middle ages is a good thing :-)

Wonderfully said.

I agree with your analysis of Dart's situation. Dart is still struggling to achieve momentum, I think. Competition like TypeScript will see Dart go the way of Silverlight. :)

I'm frankly surprised Google went with a bet on a new VM and whole new language in the first place; I would have expected them to get behind ES6 and go in a more TypeScript-like direction.

Just to be clear: Google actively supports and invests into ES6, Dart notwithstanding.

The TypeScript playground already has code completion support in pure JavaScript, so I can't imagine that functionality won't rapidly spread into IDEs other than Visual Studio.

Why do you think that that fact implies that adoption will happen quickly? I don't necessarily think adoption will be slow, but I don't see how Microsoft's JS implementation will speed things up, unless you're suggesting that many IDEs use JavaScript to implement code completion and that their frameworks for hooking into code completion are nearly compatible with what's used in the demo IDE on the TypeScript page.

It seems like IDE support is more related to how large and/or dedicated the sub-population is for a given language within a particular IDE's userbase. Actually writing the code to support a new language doesn't seem like the sticking point, especially when a grammar and specification is available.

See this reddit comment, by a member of the Dart team, on technical differences between TypeScript and Dart as languages. The summary is that it made slightly different compromises from Dart, and I like these ones better (in particular the downcasting is not implicit, giving a bit of meaningfulness to the whole typing story).

Other than that, I wouldn't say that it's a terribly interesting language from a technical point of view: if you know about ActionScript 3 (as a previous attempt to type-annotate Javascript) and Dart, there is not much innovation to comment on -- that's not the goal of the tool.

I'll note that there are no generics, and that they made the same choices as the Go team in this respect (hardcoding generics for some datatypes of the standard library).

There are things to say about the way some of those choices will help adoption (in the Socio-PLT spirit), and also how it will influence the evolution of the whole Javascript ecosystem. My sentiment is positive, and in particular I hope that closeness to Javascript will help retrofit some of the work into the Javascript standard, with accelerated uptake due to the existence a successful implementation of those ideas. If we can get decent optional typing in Javascript in 3 years rather than 10 because of this, this will already be a very good thing. I'm not sure those political aspect are the kind of comments one expect to find on LtU.

Politics? Now I can't get rid of the image of Jim Lehrer moderating a debated between static and dynamic typing. Only thing for sure, Big Bird ain't going to be too happy with the result.

It's been so long since something like The Treaty of Orlando, somehow we've separated into our own like minded communities and these debates don't really happen that much.

You realize that The Treaty of Orlando was never the topic of a home page story? Where are all the OO advocates when we need them?

if you know about ActionScript 3 (as a previous attempt to type-annotate Javascript) and Dart, there is not much innovation to comment on -- that's not the goal of the tool.

Just a nit on phrasing: it really helps to separate invention from innovation! TypeScript focuses on diffusing basic PL inventions to the browser app crowd rather than making new ones. I bet they could do more in how to do that both in terms of invention and innovation, but it's great that this is being done for more than basic syntax etc. (a la CoffeeScript).

I'm happy to see this. I think TypeScript could offer a very good path for improvement for JavaScript. Distribution with node is an excellent idea. But I... can't say I'm excited about it. I wonder why that is?

(edit: I'll add that the module system is more interesting to me than the type system.)

Thanks, it's interesting.

I regret I discovered in this blog that function input types can be both contravariant and covariant in TypeScript. I had only read that they didn't allow implicit downcast at assignment, and had assumed downcasting at call site similarly required an explicit type assertion¹. I'm disappointed that functions input types are covariant, and at a first uninformed glance it seems to me that those two different design choices are inconsistent.

¹: note that type assertions are erased by the type-checker, and in particular don't result in any form of runtime check

Most interesting part for me was Lars Bak talking about "Tree Shaking": A new buzzword for dead code elimination, seems related to a question I asked recently on StackOverflow.

Also, Anders mentioned TypeScript originally had a different version of classes, that he liked better, but they migrated toward ES6 max-min classes so that TypeScript could remain consistent with ES6. Does anybody know what TypeScript's original class system was like? Today, I spent a few hours reading discussion archives of Allen Wirfs-Brock, Dave Herman, Russell Leggett, etc. debating classes, but as an outsider, it was tough to follow, especially since I am a relative JavaScript newbie. I am guessing Anders is referring to Allen Wirfs-Brock's comparison between max-min classes and "enhanced object literals", but I can't say for sure.

Tree shaking isn't quite a new word. It was used in this sense at least as early as 1994 in Jones' Dictionary-free Overloading by Partial Evaluation.

does the rise of "classes" in javascript mean that prototype approaches are wrong, or that people are too dumb to use them right, or that there's a time and a place for either approach even in one language?

Ideally, we could build languages using primitive composition operators and compose compound composition operators from those primitives.

But, more practically, the argument for max-min classes seems to be (from my reading yesterday) that they make the code a little easier to understand, and also more uniform. Main example would be passing "self" references from a parent scope to enclosed child scopes.

As for judging other's intelligence, no thanks. The "too dumb" argument generally is the wrong way to think about why complex systems fail. Reading the comments by the EcmaScript committee members in the archives yesterday, it is good to see they all seem to share the right perspective on resilience engineering for language design.