> 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.
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.
Okay, so you are talking about exposing integer vs. double distinction (because CPUs are better at int math) and the SIMD support in the Dart VM.
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.
The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.
I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
> The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.
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.
You're complaining about more speed? Why don't we see the same complaints with asm.js?
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.
I doubt they are expecting Apple and Microsoft to incorporate the Dart VM, so they are putting a lot of effort into the JavaScript output. The Dart VM really comes into play in the near future for Chrome Packaged Apps. They interesting thing is loading snap shots of the virtual machine state quickly.
http://www.infoq.com/articles/google-dart
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.