Dart's VM isn't Chrome-only, its open source, and available both standalone and bundled into Chromium.
> However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome.
Reaction might have been more positive in the short run if it was sold as a on-top-of-JS language rather than part of a long-term plan to build something to replace (or complement) JS as a language for which browsers would have a a built-in, language-specific VM. However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
I meant that dart is chrome-only in practice. I don't know of any other browser vendor that bundles the dart vm, including the few browsers based on chromium like rockmelt or 360.
> However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
I can appreciate Google's directness regarding Dart's intention. However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
* Dart compiles to JavaScript, Silverlight did not. * Dart is actively being developed, Silverlight is not. * Dart does not require any plugins, Silverlight did. * Dart natively supports the DOM, Silverlight did not.
[disclaimer: I work on the Dart team]
I didn't think even Chrome bundles Dart, yet, either; for native Dart (as opposed to compiled-to-JS Dart), Google distributes (both separately and with the Dart SDK) a special Chromium-based browser with the Dart VM integrated called "Dartium".
For all practical short-term purposes, Dart is another compiled-to-JavaScript language, and is no more plagued by multiple backends than JavaScript (which, after all, runs on multiple different engines from different vendors) is.
And I don't see how having an optimized VM in development makes it less attractive than compiled-to-JS languages that don't have that.
> However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
I would think the fact that Dart is -- rather overtly -- immature and rapidly changing would be a much bigger barrier to adoption by relatively conservative, need-something-that-works-now, web developers. I don't see how having an experimental optimized VM available-but-not-widely-available-to-end-users factors in to making it less attractive to web developers.
It has optional types, like many compiled-to-JS languages (as lack of declared types is one of the motivations for such languages.) I don't know what you mean by "special data types for the VM". Can you provide some examples?
> They clearly want to target the VM for fast applications that aren't very usable compiled to JavaScript.
Obviously, they think that the VM will provide some benefit over compiling to JS or they wouldn't make the effort of building the VM. But, unless you can give a reason to believe that they are crippling the performance of Dart-to-JS code to push the VM, I can't see why that would be a problem.
All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS implementations that would be attainable, its just taking advantage of not being stuck with JavaScript's lack of types to further optimize the performance of Dart-on-its-own-VM.
I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
If SIMD on Dart works out well, you can bet JS will get SIMD support too, and then dart2js will use that. It's this type of competition that pushes things forward.
Yes, building performance improvements into the Dart VM that go beyond something that is found in most JS engines means that there is the possibility that (given equivalent hardware) some things that peform acceptably on the Dart VM won't perform acceptably when relying on Dart-2-JS.
Which would be a problem if there was a barrier to other browser vendors incorporating the Dart VM, or adapting it to platforms that Google doesn't support. But there's not, and the whole point of Dart -- and why there is a Dart VM -- is because Dart is an effort to provide an alternative to JavaScript, with dart2js as a mechanism to make development in Dart useful even before Dart VM adoption takes off.
But dart2js isn't the long-term goal, its a tool to get passed the problem that without runtime deployment, no one will develop, and without development, no one will deploy the runtime.
> I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
And I don't want the web to stagnate because we can't do anything that might work better than what exist now.
Good thing about new efforts being open is that they avoid both problems.