As far as native support in other browsers, it appears that Mozilla currently outright refuses to consider it on the principle that Dart is not developed openly and is not standardized, meaning that implementations in other browsers would have to reverse-engineer the Chrome implementation and would be at the mercy of Google with regard to compatibility. Unlike Mozilla, Apple and Microsoft appear to have rejected it out of pragmatism rather than principle. Specifically, Apple's Webkit engineers appear to object to the complexity and overhead a new virtual machine would add[1], and Microsoft has publicly stated that Dart doesn't solve any problems that can't be fixed in future iterations of Javascript[2].
For a more detailed technical and political perspective of why Mozilla won't implement Dart natively, see Brandon Eich's comments on the original Dart announcement[3] (it's actually quite an interesting read).
[1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
[2] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas...
The overhead of Dart compiled to Javascript will hopefully be very minimal, and in some cases Dart might generated code that runs faster than what a programmer might write.
The reason for the existence Dart VM is not because Dart->JS will be slow, it's because Dart should be able to be faster than Javascript because it's easier to optimise. The creators of V8 are writing the Dart VM, so presumably they have some ideas about how to make it faster than Javascript.
If there does turn out to be significant overhead to the transpilation phase, I'm curious if a pragmatic subset of Dart will emerge that avoids any language features that incur expensive tranformation costs, sort of like how some modern Python projects (e.g. Django) handle 2to3 compatibility by avoiding language features that are incompatible across versions to achieve a more unified codebase[1].
[1] http://groups.google.com/group/django-developers/browse_thre...
My point is that this is not really true. The Dart language itself is designed to compile to efficient Javascript.
This is one reason it's a better solution than GWT in my opinion, because Java does not always compile to efficient Javascript and you do have to skip features like longs, Java regexes, even the java.util collections classes are heavyweight. Dart being designed from the start to compile to Javascript avoids most of these problems.
Like CoffeeScript, I expect Dart performance to be very close to Javascript when compiled, sometimes even faster than what a programmer would normally write.