It is probably true that, even with a cross-compilation strategy, if Dart doesn't get adopted by competing browser vendors it will be a force towards fragmentation, which tends to be bad for the web.
An interesting question to consider, IMO, is whether a "clean break" for client programming languages is a bad idea outright, irrespective of context and motivation. If it is, it follows that the principal means for information dissemination and collaboration our species has devised will forever be programmed in the same language. It is a bleak thought, because, even if the language was faultless at its time, progress happens and the web needs to improve.
Of course Javascript can evolve (I personally very much like the proposals, and look forward to working with ES.next), but any language designer knows once some decisions are made there is no way to go back and revisit them.
If we allow for the possibility of a "clean break", then we can ask ourselves how could it be done. IMHO, committees don't fare all that well in language design. I think it would have to come from a single knowledgeable designer or a group of closely aligned knowledgeable designers. I also think it would be impossible to evaluate such a language without a real implementation. A real implementation would have to be in a real browser. So, a Browser vendor that employs experienced language designers seems like a good candidate to try a clean break, and I'd be glad if it succeeds.
Thumbnail of possible future (first is happening): ES6: modules and shallow continuations; ES7: guards, contracts, event loop concurrency; ES8: macros, parallel arrays (SIMD).
JS evolution disrupts the clean-break rationale.
Languages can change both surface and semantics. The open question I see is: can JS become the VM (its source the "bytecode") to host many languages and several approaches (none memory unsafe; no shared-memory threads).
We have lots of evidence for JS becoming the VM already, along with nay-sayers who want a clean break.
I'm going with evidence over clean-break assertions until we hit a wall that is either inherent in the language or emergent in the standards body and the market. Again, this is why I am concerned about Google playing fair.
An interesting question to consider, IMO, is whether a "clean break" for client programming languages is a bad idea outright, irrespective of context and motivation. If it is, it follows that the principal means for information dissemination and collaboration our species has devised will forever be programmed in the same language. It is a bleak thought, because, even if the language was faultless at its time, progress happens and the web needs to improve.
Of course Javascript can evolve (I personally very much like the proposals, and look forward to working with ES.next), but any language designer knows once some decisions are made there is no way to go back and revisit them.
If we allow for the possibility of a "clean break", then we can ask ourselves how could it be done. IMHO, committees don't fare all that well in language design. I think it would have to come from a single knowledgeable designer or a group of closely aligned knowledgeable designers. I also think it would be impossible to evaluate such a language without a real implementation. A real implementation would have to be in a real browser. So, a Browser vendor that employs experienced language designers seems like a good candidate to try a clean break, and I'd be glad if it succeeds.