Because it is a Google project, and other browser vendors (those mentioned in Eich's next sentence) don't want to include something from a competitor into their own browser. It'd be about like Ford proposing that GM and Dodge install Ford's GPS unit (hopefully you can relate to major US automakers).

He might have spoken too soon though (or I missed the point), as there are projects out now that I think could very well make a decent runtime for Dart. Using tech such as asm.js[1] -- which Firefox now includes natively (drawing a parallel to Google's Dart) -- along with new versions of JS, and modern JS browser optimizations....it can make for a very efficient script.

As efficient as Dart with the VM? Probably not, but I'm not sure just how much of the market you're going to corner by such an advantage. Any JS outside of a browser will undoubtedly run on NodeJS, which is going to be more efficient than Dart for most (if not all) tasks, and so it just comes to down to in-browser usage. For 99.99% of current web apps, I don't think you'd never notice a difference.

1. http://en.wikipedia.org/wiki/Asm.js

Don't listen to the hate and vitriol.

Dart has a nice IDE, good clean types and language design. People are upset because they jumped on the wrong band-wagon and now something shiner and newer came around so they are not the cool hipsters anymore. Kind of like in the kindergarten the kid with the shiny new bike is boasting then some other kid gets the later, better, shinier model, the first gets upset and throws a tantrum.

Look at Dart's performance benchmarks. Its DartVM is about 2x as fast as v8 (JS) and its compiled to JS version is on par with v8.

https://www.dartlang.org/performance/

> Dart has a nice IDE, good clean types and language design.

I have a serious problem with Dart's design: the type system is deliberately unsound around generics because the designers apparently think that supporting variance (which is not that difficult!) is worse than having types tell the truth. I would much rather there be no type system at all than there to be an unsound one, as I don't think compilers and IDE's should lie to you.

I think that's a mistake that the new language of the Web should not make, but Google seems unwilling to change it. Unlike JavaScript's warts, which be worked around for the most part, I don't see any way to fix a flaw that serious in the type system once Dart is stable.

I don't understand this. Dart is a dynamic language that gives you the option of adding types that help with tooling, documentation and some type checking at design time. At run time you can run it in checked mode and it will always tell the truth. This means that if you cover your code at all, manually or automatically then it will inform you of type errors. If you don't cover your code before releasing it then you probably are not writing anything very serious anyway. How is this worse than a dynamic language that offers you no optional typing with full checking at runtime?

> Dart is a dynamic language that gives you the option of adding types that help with tooling, documentation and some type checking at design time.

But the tooling and documentation aren't telling you what will happen at runtime.

> At run time you can run it in checked mode and it will always tell the truth.

It doesn't tell you the truth. A static type system is designed to rule out errors are compile time. That's what makes a static type system different from type assertions or guards.

Besides, I don't really know what "telling you the truth" means if, for example, function arguments unify under covariance instead of contravariance like they should. Whether that happens at runtime or at compile time makes no difference—it's equally wrong either way.

> This means that if you cover your code at all, manually or automatically then it will inform you of type errors.

This is always true in any dynamic language.

> How is this worse than a dynamic language that offers you no optional typing with full checking at runtime?

In JS's case we can still add a static type system that's actually sound, whereas Dart has already crossed the bridge into unsoundness.

>That's what makes a static type system different from type assertions or guards. This system is different from type assertions or guards in that you do not have to write any assertions but will still be informed of most type errors at compile time and virtually all type errors at runtime (Its been a while since I have written some Dart so I'm not 100% sure and don't have time to check if its exactly 100% of scenarios)

> This means that if you cover your code at all, manually or automatically then it will inform you of type errors. >> This is always true in any dynamic language.

No, there's a difference. I will get the error in dart as soon as I try to use the object in any way. In a dynamic language I could call a few methods on it before calling a method it does not support. i.e. it behaves like a compiler would except at run-time. This makes a big difference in how quickly you can debug it and again this is only for the minority of scenarios that are not covered at compile time.