Thing is, Javascript works as a target for other languages. For example ClojureScript and Scala.js are examples of compilers targeting Javascript, amongst many others. So people that want an alternative to Javascript already have options.
From a technical point of view, I think Google made a mistake in designing a new language, instead of a new VM that could be used as a more efficient target for multiple languages, because even though Google tried copying the good parts of Javascript's story, you can't beat the incumbents at their own game. And from a social perspective, Dart is seen as an attempt to fragment the web, so Google's handling of the situation was poor.
# JS has shown surprising legs when it comes to performance improvements
# For a competitor to become popular it’d have to persuade every browser manufacturer to implement it
# Once implemented it’d have to wait for multiple years for devices in the market to implement it
# Older devices are slower devices, so having a compiles-to-JS version that lags in performance for older devices isn’t tenable either.
Basically, it makes more sense to increase the local maximum than any other path.
IMHO this is a misconception. Dart compiles to JavaScript with decent performance of the generated code. In some cases even faster than comparable hand-written JavaScript (see: http://dartlang.org/performance).
JavaScript engines getting faster also means that Dart code compiled to JavaScript is getting faster. It is a win-win scenario.
Even if other browser vendors won't ship a Dart VM tomorrow the situations is pretty awesome performance wise.
Once Chrome ships a Dart VM a huge user base gets even better and more predictable performance characteristics than would be possible in JavaScript which is incredible but I don't see the browser vendor support/performance angle as a real show-stopper for Dart.
You don't give anything up when you use Dart, you can still call JavaScript libs if you need to (e.g. we do use PubNub.js at https://www.blossom.io and we use it from Dart without any problems).
There's plenty of other javascript compilers for plenty of languages.
Because you don't want to write your backend in Javascript and you prefer a different language. You don't have to know well only one language in your lifetime.
Libraries. Backend code can be quite different than frontend depending on your requisites.
E.g., there's no SQLAlchemy for Node.
HTML and CSS are quite different things, you can't escape that.
Right tool for the right job. That's why I don't think you should use css on the server! Or haskell on the client's browser!
I'm sure it's a perfectly valid option to put in the browser, though.