At the same time nobody else agrees on this language and currently only a branch of chromium supports the VM.

This is rather political - everyone want to have controls over the next language of the web, and nobody would want to adapt one made by others.

What even worse is that we all know it's almost impossible to create a good language without some dictatorship at the beginning.

The reasons why others aren't adopting Dart are only partly political, and not for the reasons you make out: the political side of it is that most (all?) other browser vendors would much rather only add a new language with an openly developed specification for it; the technical side is there's no way to integrate it into the browser without taking a performance hit both for Dart and JS.

Dart has an open specification: http://www.dartlang.org/docs/spec/latest/dart-language-speci...

The entire project is open, the VM, the dart2js compiler, the libraries, the package manager.

As for a performance hit when integrating with the browser, what re you talking about? Any references?

An open specification, sure. But the specification is for all practical purposes controlled by Google: it's not an open standard as a result. (On the plus side, the specification now looks like it may actually be viable to make an independent implementation, which it certainly wasn't before!)

The performance hit is that inherent of having to have multiple GCs given the multiple VMs. This is part of the reason why support for non-JS VMs didn't get into WebKit proper: <https://lists.webkit.org/pipermail/webkit-dev/2011-December/.... Various citations to research around there are listed in that email.

Dartium doesn't attempt to do cross-VM GS, so that supposed overhead isn't there.

I'm not sure any such overhead would always occur, or would only happen if both VMs were in use and there were cross-heap references. It'd doesn't seem likely that cross-heap GC would have such an impact with only one heap.