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.
Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native.
Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance.
There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript.
The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower)
The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.
The asm.js comparison is a false equivalence. It is not possible (without explicit effort, e.g. checking the UA string) for Web authors to ship asm.js that does not work in Chrome, because asm.js is just JavaScript. With Dart, Web authors may end up not shipping the JS fallback, or not testing it, thus locking the Web into Chrome. That is why turning on the Dart VM for Web content would be a problem.
It's a false equivalence in theory, but in practice, I don't think so. Realistically, how many developers are not going to ship something that doesn't work on Firefox and Safari, especially, Mobile Safari? Especially when the tools to do this are trivial and automatic.
It's much harder to write cross-browser CSS, with full GPU compositing, and responsive layout than it is to compile Dart to JS. What is the incentive for the developer not to do is and leave a huge chunk of marketshare on the table with little effort?
Stuff like prefixed-CSS is a far far worse threat to the Web than a DartVM.
Of course people won't ship something that doesn't work cross-browser today. But by that logic, no proprietary feature is worth worrying about. Consider a hypothetical future in which Chrome had 90% market share: as a Web dev, would you bother shipping or testing the JS fallback?
If Chrome gets 90% marketshare, there'll be other problems besides Dart. History also tells us that even if all vendors adhere to standard specs, there will be implementation differences and bugs that still require developers to write browser specific code and fixups.
Again, I'm not disagreeing that there is a danger of fragmentation, but this won't happen because of Dart, but because of other forces. The criticism over the DartVM is being blown way out of proportion.
The best defense against any of this happening is not to protest Dart, but to make sure the browser market is competitive.
>With Dart, Web authors may end up not shipping the JS fallback
Why wouldn't you? Minifying Dart or compiling Dart to JavaScript is basically the same. You invoke the very same command line tool just with different switches.
Why would you do one thing in your build/deploy script but not the other? Especially if doing so makes it incompatible for a significant chunk of your users. Most people won't even drop a 5% chunk (e.g. something like IE8).
> 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.
Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native.
Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance.
There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript.
The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower)
The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.