> Dart is no more an attempt to replace the web with a walled garden than GWT is (which is what I work on). It is a tool, like Typescript, like CoffeeScript, like ClojureScript, like Emscripten. There's no "plan" to create a lock-in walled garden based around programming language.
Regarding the Dart language, I agree fully. It's another option like the ones you mentioned. They all generate JS, and since we have pretty good guarantees of JS running the same on different browsers, everything is interoperable.
But regarding the Dart VM, there is a concern. Of course the Dart VM on the server etc. is fine, but there is an issue in the browser: If Google ships the Dart VM in Chrome, and the Dart dev tools generate a 'fat build' containing both Dart and JS, and Chrome runs one while the rest of the world runs the other, we are at risk of fragmenting the web.
As Chrome's market share rises, many people are testing first and foremost in Chrome. It is possible that they will not include the JS part and ship only the Dart part, or that they will do far less testing of the JS part, leaving it suffering from bugs and performance faults.
Even if the Dart VM is open source, that is a bad situation that could break the web as we know it.
> The way I see the potential of a DartVM is the same as OdinMonkey+asm.js
The crucial differences is that asm.js is a strict subset of JS. There is 0 risk of someone shipping something that only runs in one browser - it is literally JS, and will run fine everywhere.
(And not just will it run, but it also runs quickly everywhere, because asm.js is not a random new subset but the result of a long-running industry trend, for example in this link asm.js code was fast on 3 different browsers http://j15r.com/blog/2013/07/05/Box2d_Addendum )
I agree CSS and various API issues are a high threat. In many cases they are a problem right now.
But I disagree it is 1% for the risks mentioned before regarding the Dart VM in Chrome. It's hard to estimate that. If Chrome continues to increase in market share, it will no longer be a "huge chunk" of the market that they lose if they do not support dart2js, and furthermore, it isn't just a matter of working or not, but also how much focus on bugfixing and performance work they put on the JS fallback. It's easy to imagine many developers (especially smaller ones) developing in chrome and testing in chrome, and just verifying basic stuff works in other browsers.
We are not far from that risk today in other areas, for example important sites like Google Docs already say "For an enhanced and optimized experience, use Chrome". The risk gets that much worse when Chrome is actually running completely separate content in the Dart VM from everyone else.
If Chrome gets 90% marketshare, even if they don't ship DartVM, and even if they only implement approved specs, there will be differences in implementation and bugs that drive developers to make sites that don't work on other browsers. We saw this with IE bugs when IE was dominant.
The only defense against this is to preserve competition. My continual criticism in these HN threads is that people's vision is too narrow, too focused on irrelevant battles, focusing energies in the wrong place.
These are two battles going on right now. WebKit derived vs Mozilla, and Web vs native Mobile. The latter is a serious threat and no one is really offering anything to attack the problem. And no, FirefoxOS and asm.js doesn't.
Simply put, consumers find it easier to find and buy content on native platforms, and developers find it easier to use tools on native platforms. The Web has a huge looming consumer and developer problem. A lot of people who sit around in VIM/Sublime all day hacking MVC or jQuery websites don't seem to realize the looming problems.
Web Development needs to be made radically more productive. Web Performance needs to be radically upped. The current tap dancing around ES6 improvements or ION/ODINEngine are nice, but simply too underwhelming.
Web Components are a step in the right direction. But honestly, if I wasn't working for Google right now, I wouldn't be writing a web app these days, I've be writing an iOS or Android app.
Both Google and Mozilla have huge problems to solve IMHO, and this bickering over Dart, NaCL, Asm.js, et al is a big distraction. These organizations need to work together to make the web delightful on mobile and for developers as the whole industry transitions.
Yes, on mobile native is winning. I'm not sure there is much Google and Mozilla can do though. The main platform for app developers is iOS. The only way to counter that is to take market share from iOS (a goal towards which everything that can be done, is being done).
People make iOS apps and not web apps because iOS apps perform better on iOS than web apps on iOS. And iOS is where most app money is made. Making the web a better platform in general won't directly help with that, important as a goal it is.
I don't agree there is "bickering" over Dart, NaCl/PNaCl, asm.js. There are issues of principle there. For example, if we make the platform stronger but it loses some of its core attributes (like portability were NaCl to be adopted) then the whole thing is at risk of becoming pointless. At the same time, we do need to make the platform stronger and competitive in terms of speed with native as much as possible, which is a fine line.
Regarding the Dart language, I agree fully. It's another option like the ones you mentioned. They all generate JS, and since we have pretty good guarantees of JS running the same on different browsers, everything is interoperable.
But regarding the Dart VM, there is a concern. Of course the Dart VM on the server etc. is fine, but there is an issue in the browser: If Google ships the Dart VM in Chrome, and the Dart dev tools generate a 'fat build' containing both Dart and JS, and Chrome runs one while the rest of the world runs the other, we are at risk of fragmenting the web.
As Chrome's market share rises, many people are testing first and foremost in Chrome. It is possible that they will not include the JS part and ship only the Dart part, or that they will do far less testing of the JS part, leaving it suffering from bugs and performance faults.
Even if the Dart VM is open source, that is a bad situation that could break the web as we know it.
> The way I see the potential of a DartVM is the same as OdinMonkey+asm.js
The crucial differences is that asm.js is a strict subset of JS. There is 0 risk of someone shipping something that only runs in one browser - it is literally JS, and will run fine everywhere.
(And not just will it run, but it also runs quickly everywhere, because asm.js is not a random new subset but the result of a long-running industry trend, for example in this link asm.js code was fast on 3 different browsers http://j15r.com/blog/2013/07/05/Box2d_Addendum )