I see where you are coming from, and I think this was a very well-reasoned argument.
In my opinion though, your argument prioritizes browser vendors over users, and over the competitiveness of the web vs. competing technologies like native apps.
Let's take your scenario, where somehow the Dart VM become becomes noticeably faster than Dart2JS on Google properties, to the point that users notice and get a better experience by using a browser with the Dart VM embedded.
First of all I'd mention that there is a natural competitive pressure that keeps Gmail and other Google properties "honest" so-to-speak. Chrome is far from being the only web browser, and if Gmail is perceived as being slow compared to other webmail websites, Gmail will suffer accordingly. Gmail has no incentive to cripple the speed of JS-only browsers; it has the incentive to make its app as fast as it possibly can on all major browsers.
So if hypothetical future Dart-Gmail is noticeably faster than JS Gmail, then it is likely for some fundamental reason of Dart being more optimizable, and not because of any lack of effort to make the JS version fast.
At this point, where the Dart version is faster for purely technical reasons, you say that "adopting the VM might be the only option" for other browsers. I would say first of all that it seems that there are other options, like compiling Dart to asm.js in a very peripheral part of the browser so that you wouldn't have to change your core execution VM. Given that the Dart VM is open source, this would be adding a new backend to an existing compiler (sort of like you did with Emscripten and LLVM), and not an effort comparable to developing a new compiler from scratch. It's true that this would require you to adopt some third-party code, but it would keep the Dart VM out of your browser, if not the Dart compiler.
But suppose that even that wasn't acceptable or feasible. Now the question is, is it better for (some) users to get the advantage of technology that has demonstrated that it is inherently faster, at the cost of other vendors being pressured into adopting this (standardized) technology, or is it better for all users to be equally disadvantaged, to keep the browser playing field more level?
As you surely know, browsers aren't just competing against each other, they are competing against other app platforms like native apps. If the web stays a little slower but all browser vendors are more equal, then the whole web is falling behind compared to the other, far less open and level, app platforms.
Now all of this discussion is quite premature until/unless Dart is actually distributed as part of Chrome, and the Dart VM is actually found to be noticeably faster than regular JavaScript, and Google actually uses Dart on its big properties.
Well, the Dart VM is not like adding a backend to a compiler or VM - it is a complete VM in itself.
For example, it has its own concepts of references etc., which means that if you add the Dart VM alongside your JS VM, you need to be able to collect cycles spanning those two.
That is not a trivial thing to do, and in fact Google has been working for a while on the Oilpan project to make Chromium capable of collecting such cycles, that span C++, v8 and the Dart VM. It's a huge engineering effort. Gecko can currently collect cycles between C++ and JS, but extending that is not trivial, and I believe Safari cannot collect such cycles and instead by design avoids creating such cycles - but that would not be possible with the Dart VM.
It might not be practical for other browsers to adopt such a technology. So if Google sites force the Dart VM to be necessary to compete, that would basically mean that the other browsers cannot compete. Then there would be just Chrome, a single implementation of a web browser, dominating the market like IE used to.
It might be good for users to have a single browser for a while, single implementations can move faster without regard for standards or openness. But lack of standardization and openness also means it is a proprietary platform, of which we already have many.
> Well, the Dart VM is not like adding a backend to a compiler or VM - it is a complete VM in itself.
My straw-man idea was not to add the Dart VM to the browser, it was to add a Dart-to-asm.js compiler to the browser, as an AOT compilation step. This would not involve integrating the VM at all.
> It might not be practical for other browsers to adopt such a technology.
Given that there are at least three completely independent and highly competitive JavaScript JIT-compiling VMs from a variety of different browser vendors, I find this unlikely.
I think we are four levels into hypotheticals here. If every technical advance was rejected due to something bad that might happen four steps down the road, nothing would ever improve.
We surely never would have gotten JavaScript. That could have gone badly in tons of different ways (especially since, as the first execution engine in a browser, there was no backward-compatibility strategy). Who would have believed in 1995 that 15 years later this technology would have gotten pushed so far, and that the competition would be so healthy?
> So if Google sites force the Dart VM to be necessary to compete, that would basically mean that the other browsers cannot compete. Then there would be just Chrome, a single implementation of a web browser, dominating the market like IE used to.
The entire web platform is standardized (including Dart, which is standards-track). I would challenge you to name a standardized technology with a market comparable to the web in which one vendor is so dominant that all of the other competitors are defeated and it becomes a monoculture, despite a large demand.
If anything, I think the prospect of a web that cannot keep up with other application technologies far more likely and troubling.
> My straw-man idea was not to add the Dart VM to the browser, it was to add a Dart-to-asm.js compiler to the browser, as an AOT compilation step.
Oh ok, sorry for misunderstanding you.
That might work, but it is unclear it would be any faster than dart2js. Also, AOT is not likely to work in Dart which is optionally typed, unless a codebase is actually fully typed. Overall it seems an interesting experiment perhaps - I've suggested it myself - but an unlikely one.
> I would challenge you to name a standardized technology with a market comparable to the web in which one vendor is so dominant that all of the other competitors are defeated and it becomes a monoculture, despite a large demand.
Well, the web - back in the IE days.
Also to a lesser extent the smartphone mobile web which was a monoculture of WebKit (and to some degree still is today).
And the point is that standards become irrelevant when there is a monoculture. In theory windows supported various POSIX APIs, but in practice windows became a proprietary monoculture.
In my opinion though, your argument prioritizes browser vendors over users, and over the competitiveness of the web vs. competing technologies like native apps.
Let's take your scenario, where somehow the Dart VM become becomes noticeably faster than Dart2JS on Google properties, to the point that users notice and get a better experience by using a browser with the Dart VM embedded.
First of all I'd mention that there is a natural competitive pressure that keeps Gmail and other Google properties "honest" so-to-speak. Chrome is far from being the only web browser, and if Gmail is perceived as being slow compared to other webmail websites, Gmail will suffer accordingly. Gmail has no incentive to cripple the speed of JS-only browsers; it has the incentive to make its app as fast as it possibly can on all major browsers.
So if hypothetical future Dart-Gmail is noticeably faster than JS Gmail, then it is likely for some fundamental reason of Dart being more optimizable, and not because of any lack of effort to make the JS version fast.
At this point, where the Dart version is faster for purely technical reasons, you say that "adopting the VM might be the only option" for other browsers. I would say first of all that it seems that there are other options, like compiling Dart to asm.js in a very peripheral part of the browser so that you wouldn't have to change your core execution VM. Given that the Dart VM is open source, this would be adding a new backend to an existing compiler (sort of like you did with Emscripten and LLVM), and not an effort comparable to developing a new compiler from scratch. It's true that this would require you to adopt some third-party code, but it would keep the Dart VM out of your browser, if not the Dart compiler.
But suppose that even that wasn't acceptable or feasible. Now the question is, is it better for (some) users to get the advantage of technology that has demonstrated that it is inherently faster, at the cost of other vendors being pressured into adopting this (standardized) technology, or is it better for all users to be equally disadvantaged, to keep the browser playing field more level?
As you surely know, browsers aren't just competing against each other, they are competing against other app platforms like native apps. If the web stays a little slower but all browser vendors are more equal, then the whole web is falling behind compared to the other, far less open and level, app platforms.
Now all of this discussion is quite premature until/unless Dart is actually distributed as part of Chrome, and the Dart VM is actually found to be noticeably faster than regular JavaScript, and Google actually uses Dart on its big properties.