Quoting Bob Nystrom:

TypeScript seems nice if you like JS semantics or have a large JS
codebase that you’re invested in but you’re having maintenance
problems at scale. It’s path for success is much smoother since it’s
(mostly?) backwards compatible with JS.

Dart is taking a riskier bet. It’s farther from JS in a lot of ways
which is, I think, mostly good as a day-to-day Dart programmer, but it
makes the barrier of entry higher. But in return for that higher
barrier of entry, you get:

• Tree shaking
• Getters and setters (though I presume TypeScript will get those eventually)
• Operator overloading
• Real block scope, no hoisting, no IIFEs
• A native VM
• Sane equality semantics
• No weird implicit conversion craziness
• Lexically bound this everywhere
• Mixins
• Annotations
• An import system
• User-defined subscript operators
• Generics, with reification
• Mirrors
• Better collection classes
• A cleaner DOM API

Also, he writes in http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd :

I’m on Google’s Dart team, so I’m naturally looking at it from that
angle/bias. Here’s some random stuff that caught my eye, mostly
comparing it to Dart. I’ve only spent a few minutes skimming, so don’t
take any of this too seriously…

No generics

I guess some types are better than no types at all, but
it’s really rough to lose those. TypeScript does have built-in array
types and object types cover some of the “map” type use cases. But not
being able to define your own generic types is a drag. The docs say
when added, generics will work using type erasure, which is what I’d
expect given it’s “compile to lightweight JS” style, but that can be a
pain too. It’s nice to be able to do stuff with your type arguments at
runtime sometimes.

All types are nullable

Dart is the same way. Makes me sad in both
cases.

The type annotation syntax is nice

Almost every language with
optional type annotations (ML, Scala, F#, Kotlin, etc.) goes with
“postfix after a :. Dart tries to use C-style type annotations which
causes some nasty corner cases. I like what TypeScript has here,
especially the syntax for function types:

Plain text

Copy to clipboard

Open code in new window

EnlighterJS 3 Syntax Highlighter

<code>function takeCallback(callback : (n : number) => number)

{ ... }

</code>

<code>function takeCallback(callback : (n : number) => number) { ... } </code>

function takeCallback(callback : (n : number) => number)
{ ... }

Interfaces are structurally typed, classes are nominally typed

Makes sense given that
it’s JavaScript, but it seems pretty neat. Being able to implicitly
implement an interface is nice. But TypeScript doesn’t seem to let you
go the other way: given a class, you can’t make a new type that’s
compatible with it without concretely extending it because of the
brand stuff. In Dart, thanks to implicit interfaces, you can.

Best common type can fail

That means this is a type error:

Plain text

Copy to clipboard

Open code in new window

EnlighterJS 3 Syntax Highlighter

<code>[1, true]

</code>

<code>[1, true] </code>

[1, true]

You can overload in interfaces by parameter signature

This is really cool
because it gives you a way have more precise type inference flow
through a function call that does some dynamic type switching. For
example:

Plain text

Copy to clipboard

Open code in new window

EnlighterJS 3 Syntax Highlighter

<code>interface Doubler {

double(s : string) : string;

double(n : number) : number;

}

</code>

<code>interface Doubler { double(s : string) : string; double(n : number) : number; } </code>

interface Doubler {
  double(s : string) : string;
  double(n : number) : number;
}

With this, when the compiler sees a call to
double, it can correctly give you a precise return type based on the
inferred argument type. What I’m not sure is how to actually implement
a class that implements that interface and makes the type checker
happy. You can’t actually overload concrete methods, and my five
minute attempt to make it happy by dynamic type checking didn’t seem
to work.

There’s a dedicated syntax for array types

Makes sense since
there’s no generics. It’s also nice and terse, which is good, but I
personally prefer general-purpose generics over one-off special case
collections.

There’s no implicit downcasting

One of Dart’s more
unusual type system features is that assignment compatibility is
bidirectional: you can downcast without a warning. Aside from the
typical special case of assigning to/from any (dynamic in other
languages), TypeScript doesn’t allow that. You have to type assert.
Personally, I like TypeScript’s approach here.

Arrow functions and lexical this

This is just motherhood and apple pie. I like it. (Dart
has this too, and this is always lexically bound.)

Overall, it looks
pretty neat. If you want exactly the same JS semantics (good and bad)
but also want a smattering of types, TypeScript seems decent. It’s
like Closure Compiler but with a better syntax.

If you want something
that’s a more aggressive step away from JS’s syntax and semantics,
then it seems like TypeScript isn’t that.

While the question was “Are the purposes of the languages the same?”, the real question is: “How can we make web programming better from where we are?”.

Both projects try to do this considering

• programming language (TypeScript makes a small but very clean step, Dart makes the more revolutionary move that is still moving)

• interoperability with existing js code (0 transition in TypeScript which compiles to js, complicated in Dart, since 2 VMs talk to each other)

• software engineering practices (Dart only, web components and shadow dom)

Over the last 3 days I dived deep into Dart and then into TypeScript. My CoffeeScript codebase went to 2000s lines of code, too much to be handled with lovely but too fluffy CoffeeScript. The problems I faced was that CoffeeScript lacks features that languages designed for medium to large scale programming have: interfaces, modules, type safety. But there was one even much more serious issue with coffee and js: The js “this pointer” weirdness affected my sanity and CoffeeScript does not help anything here.

So here my results after 3 days of eval and usage:

Dart

Went thoroughly through the tutorial, reading 1 book, skimming 2nd book and tried the demos. I thought, Dart that is the future. Then I tried to migrate my app to Dart. That was were my enthusiasm went down from 100 to 10. Here is why:

1. The Dart Editor is the only way to program Dart. While plugins for Sublime Text exist, they do not provide features like intellisense, code completion (correct me if I am wrong). The Dart Editor is however in pre alpha quality. While it does support supercool magic things like updating the web page when you edit the CSS file (! really cool) it hangs or crashes several times a minute. So you type 5 letters and 2 times you have to wait 2 seconds or 15 seconds between typing. And I had a project with some lines of code, so did not want to wait what happens when 1000s lines are in. Moved a file from one folder to the other inside Dart Editor, crash. Debugging with the Dart Editor is at first sight better than all js debugging tools I know (chrome is my choice), but there are still too many things missing: No immediate window (this makes js debugging much better at the moment), no watches.

2. Politics and Escape Possibilities: Some say that Apple, MS and Firefox will never ever provide Dart VMs. Well, I am not so sure, but at least for Apple this appears at the moment very certain. For the others its more likely than the opposite. So no problem, we can convert Dart to JavaScript. The way this integration works is really great, Dart maintains a js stub that keeps the js code connected to the Dart Editor, so a print() statement still appears in Dart Editor, cool. But here comes the but: the footprint of such converted code is high. 150kB or so (before minification). I did not dig too much into the exact size, so do not nail me down on this.

3. Language Maturity. Beside the way too serious issues with Dart Editor popping into my face 3 times a minute I also found it unacceptable that every source about Dart code you find uses a different Dart. The language changes every day. You find a post from 5 weeks ago? It is outdated. You try the samples from the Google tutorial? At least 1 sample does not compile since an API changed. Even mundane things, like attaching an event to a DOM element are in good move.

4. Integration with existing js libraries is a bit involved. 2 VMs need to communicate here, its tricky.

As a conclusion, you cannot seriously use Dart as of today, and diving into it is not too much fun due to 1 and 3. Both points will disappaer over time. About the 2 point, Google published performance benchmarks some days ago demonstrating that their compiled js is better than handwritten js. My compliments, great job. Loading time might still be behind due to the footprint issue as said. However, if the footprint code gets used by many many sites, it might be available cached and voila, disappears as well.

So: I consider Dart a great project, using it at the moment carries a good portion of unforeseeable risk and it will take this year to get it to good stable level.

TypeScript

Evaluating TypeScript is very easy, takes 1 or 2 hours and you know everything. Reading the language spec document and a short book (TypeScript revealed) revealed, I knew everything and started programming. I was then surprised to find that TypeScript’s additions to JavaScript just fill every serious need I had to enhance my client programming. Here the highlights:

1. Interfaces. Encapsulation and interfaces allow me to structure my code easily. Perfect!

2. Class State.. TypeScript allows to express the state that instances of a class carry explicitly, or better it enforces it. This is a large step better compared to js or coffee.

3. this call craziness mitigated. Inside arrow functions, TypeScript makes the this pointer like any normally behaving citizen.

4. Editor, Intellisense. TypeScript comes with 100% top perfect intellisense that reacts in the micro or millisecond range as used from Visual Studio when programming C#. TypeScript headers for all important js libraries exist too. Great great great.

5. Experience and Risk. Using TypeScript carries zero risk, the language is clearly defined, perfectly stable, it is just js with sugar, nothing unforeseeable.

Actually, these enhancements give me everything I needed. The only thing I would like to see in the future are generic collections. But that is peanuts.

So what about performance? While I consider myself a performance freak, I do not believe that there is any project that would make the technology choice here based on performance. Both are in the js liga.

If you are interested in the future of web programming, both are great efforts, TypeScript is much more pragmatic and usable now, Dart is a very interesting lab project that will be usable once mature editors and debuggers are available and the scope of projects doable with it will depend on politics.

In any case the 3 eval days were mostly fun and I learned a lot, if you find the time, it takes 1 day for Dart and 2 hours for TypeScript to make your own opinion. Try it.

Update October 2014

It has been a while and ex post it appears the assumption that Typescript is the safe stable route to go was quite right. I just found a (very) prominent statement about Typescript, Dart and Closure:

I have been interested in the challenge of Web programming in the large for quite some time. I believe that Google Closure is currently still the best option for large-scale JavaScript/Web development, but that it will ultimately be replaced by something that is less verbose. Although Dart shows considerable promise, I am still dismayed by the size of the JavaScript that it generates. By comparision, if TypeScript can be directly translated to JavaScript that can be compiled using the advanced mode of the Closure Compiler, then we can have all the benefits of optimized JavaScript from Closure without the verbosity. What’s more, because TypeScript is a superset of JavaScript, I believe that its syntax extensions have a chance of making it into the ECMAScript standard at some point, whereas the chances of Dart being supported natively in all major browsers is pretty low.

http://blog.bolinfest.com/2013/01/generating-google-closure-javascript.html

Michael Bolin is a long time (ex)google (ex)fb front end hero, also involved in google closure (get his book about Closure).

Google Traceur

Google’s appraoch to live ECMA Script 6 today is its Traceur project:
https://github.com/google/traceur-compiler

Compared to Typescript, tooling support is presumably far behind as of today. On the upside however, it is much faster in adopting overly cool future js language ehancements like iterators or comprehensions.

Facebook Flow, Google AtScript

provide similar features as TypeScript.

“One may wonder what’s with these different JavaScript type checking solutions and what to do about it. A good news is that Microsoft, Facebook and Google are collaborating on these, according to Microsoft’s Jonathan Turner:

The TypeScript team is working with both the Flow and AtScript teams to help ensure that resources that have already been created by the JavaScript typing community can be used across these tools. There’s a lot these projects can learn from each other, and we’re looking forward to working together going forward and creating the best tools we can for the JavaScript community. In the long term, we will also be working to fold the best features of these tools into ECMAScript, the standard behind JavaScript.“

infoq article on fb flow

Quoting Scott Hanselman:

People have compared TypeScript to Dart. That’s comparing apples to
carburetors. TypeScript builds on JavaScript so there’s no JS interop
issues. Dart is a native virtual machine written from scratch. Dart
interops with JavaScript…but it’s not JS. It doesn’t even use the
JavaScript number type for example.

From Why does TypeScript have be the answer to anything?

Had to chime into this discussion with my own finding lately.

1st: TypeScript

MS has taken a nice approach in the fact that you can easily jump in and out of TS and JS. We mainly use AngularJS for our development and have found while not much documentation exist for converting Angular to TypeScript. It has been a nice addition to incorporate TypeScript into our Dev workflow.

2nd: Dart

Dart is a bit of an ironic step for Google. Maybe they don’t remember activeX and all of the nightmares around trying to get an application working in anything but the dreaded IE 5 or IE 6 of the day. It has taken MS many years to recover from those days.

Dart as a language “conceptually” seems to try to combine some nice OOP features. Annotations etc are a nice thought for Javascript.

The problem, it is hard to imagine enough bandwidth to create a new editor, new language, new vm’s across browsers, plugins for other IDE’s, compiler to convert to javascript (without being multiple meg in size), convert or create new dart libraries to replace the thousands of current js libraries, have someone decide polymers or directives, convert the dartlang site to use dart, this is what I can think of off the top of my head.

The concept of trying to use Dart in anything but a trivial app at this time is scary.

On top of all of this ES6 is not far away. ES6 brings many features that Dart is trying to fix that exist in ES5. What will the value proposition be once ES6 hits the streets? At least at this time the only change you have to make in TypeScript once ES6 comes out is to maybe choose a different compile to target.

Just to clear up any though that I am a pro MS person. MS makes some decent products and has made great strides to fix past mistakes with the OSS community. I still vary rarely use anything other than TypeScript from MS.