Yeah, tone can be hard to guess from text. Figured the link would be helpful either way :)
disclaimer: I'm on the Dart team (libraries, not core language/VM/dart2js). As exciting as it would be to have Dart VM in Chrome, personally I hope the order is more like:
* dart2js and VM work the same way (basically true already, modulo a few quirks unlikely to affect program behavior. It's not any worse than your typical web standard polyfill, probably a lot better.)
* The language spec is standardized.
* People like Dart, and it becomes really popular for building web apps.
* We have great Dart<->JS interop and it's possible to make the two native VMs work nicely together in the same browser.
* The toolchain makes it practically impossible for a web developer to publish an app that only has .dart files, without the .js version that works on all browsers.
* At that point, it might make sense to add the Dart VM to a browser purely a performance optimization.
Of course a lot could change between now and then. For example, if JS engines keep getting faster and introduce enough fast stuff (like typed arrays, asm.js, etc), maybe we can achieve the speed we need with dart2js.
Fortunately, there are plenty of folks that work on Blink/Chromium that share both the enthusiasm and skepticism that the web community has about Dart. As someone that works on it, I deeply want our team to succeed, but I would like to see it happen in the right way--open web and open source friendly.
yeah, if you're running directly on a VM for the language (e.g. JS on a JS engine, Dart on a Dart engine) you wouldn't need source maps for debugging, unless you are using some other tool that is doing source->source transforms for you (e.g. https://github.com/dart-lang/web-ui currently does some dart->dart source transforms). You'd still have source maps for the dart2js output.
