The first & second parts certainly seem like evolution to me. The slower performance than native JS issue remains to be seen. I believe Dart, when fully baked

The first & second parts certainly seem like evolution to me. The slower performance than native JS issue remains to be seen. I believe Dart, when fully baked, will generate code very similar in performance to "native" JS. In fact, I think it'll probably be better than your average hand-rolled JS code that doesn't use something like Google's Closure Compiler already. In any case, unless the generated code is substantially slower than "native" JavaScript (which there is no basis to believe will be true), this is a bit disingenuous of an argument coming from the web crowd who also advocate writing mobile web apps instead of native apps where you're taking a big speed hit for other benefits. Software is all about making trade-offs (hopefully the right ones). As far as a more difficult debugging experience -- I think Dart will offer the opposite, a much richer debugging experience for the developer's own code in the form of debugging within the native Dart VM. The non-Google developer shouldn't have to debug issues that arise due to the JS translation layer, that's on Google to get right, and again if they don't get that right developers just won't use the technology. I certainly think that whatever Dart's debugging experience ends up being will be much better than the debugging experience for CoffeeScript and other X->JS languages that the JavaScript-only crowd like to reference when talking about how JavaScript is already an adequate "VM". As far as Google shoving it down everyone's throat -- what is your basis for that claim? What have they shoved down everyone's throat so far? Wave? With all due respect to Google, they don't have the power to shove anything down developer's throats. They can simply develop new technology and hope that it offers developers enough real-world benefit that they will adopt it organically.