Seems that the story is they are moving towards a more opinionated language/framework. That it is Dart isn't the story here; they don't even mention the Dart VM as a benefit for the switch. It just as easily could be ClojureScript, which provides all of the same benefits.
As mraleph already mentioned the Dart VM is very useful for the instant-feedback development experience that you get from working with Dart.
It would be awesome to see it in Chrome or other platforms going forward but having it from the start is a big plus for day to day development and for the people building infrastructure on top of Dart.
There are also people who do exciting stuff with the VM in node-like scenarios.
I personally can't comment on that because we haven't looked into that use-case yet (our backend is in Python and App Engine does not support Dart yet) I'm very interested in the VM and I guess we'll see some interesting things in this area going forward.
Even though Dart VM is not a deployment target for the client side code right now it is still an integral part of the development experience. It runs all your code while you develop (no need to compile to JavaScript just edit&refresh) and backs things like dart2js, dwc, pub which are all written in Dart itself.
Also, IANAL but I'm pretty sure you don't have to include a disclaimer to post on the internet. No one is going to rush out and buy Google stock based on your comments so there is no conflict of interest to what you wrote.
[regarding the disclaimer: I add it for two reasons. First, I have seen people accusing others of hiding their bias, so I prefer to state my affiliation explicitly. Second, if anybody wants to ask any Dart VM related questions and get response they know where to ask :-)]
/me ducks
:)
The Dart2js compiler could easily take advantage of asm.js additions, and generate javascript code that uses asm.js. If asm.js does take off, all it can do is help Dart generate faster running code.
Now, if we are talking about the DartVM, asm.js could be used as an argument not to include the DartVM in other browsers. But asm.js is still very much in it's infancy, so we really need to wait and see how it's adopted and how it progresses.
It would be very interesting to see a benchmark of emscripten/SomethingMonkey/asm.js vs emscripten/DartVM.
(Could also add emscripten/dart2js/V8 for giggles)
> That it is Dart isn't the story here; they don't even mention the Dart VM as a benefit for the switch.
Which I think is equating Dart with the VM? Then you say:
> They are switching because they like the language/ecosystem better.
That sounds to me like Dart is the story then. The language/ecosystem is Dart, isn't it? Can that be separated somehow?
Server side is were people are looking for nicer solutions that what's available, even moving away from RoR towards more one-page-app friendly stacks.
It's also an area were IE compatibility doesn't matter (because we're server side), whereas raw speed, good tooling, type checks and such matter a lot, so it plays to Dart's strengths, especially if it could provide both a freaking fast raw server performance (the way V8 is already 10x faster to PHP and Python) AND a good async story with futures, that for Node.js are bolted-on.
Inspiration comes from Express for Node, but it is similar to what you can achieve with flask.
Give it a look, and file feature/bug requests if you want to see something or something breaks.
I know of 1 person that implemented a Google Oauth endpoint with it, so it does work well.
That doesn't seem to be the case. Dart provides great tooling and you can also step-debug your code from within the IDE. The workflow with Dartium (Chromium with embedded Dart VM) is pretty neat. The performance of the generated JavaScript is pretty good, too. There are also Dart Web Components which give you custom tags (with shadow DOM) and two-way data-binding.
Finally, Dart, with its "boring" C-like syntax, is familiar to pretty much anyone.