I don't speak for the team but I believe I can add some perspective.
Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases.
Google has some incredibly large and ocmplex JS apps (eg GMail). While GMail isn't written in GWT, GWT is aimed at that kind of application with deferred binding and the benefits of static type analysis.
What if you took that expertise (of GWT and static type analysis in producing Javascript) to produce a language that could run on the server, run in the browser (for browsers that support that) and compile to Javascript (for browsers that don't)?
The last point is particular is key to driving adoption as no one is going to develop only for Chrome.
I see it as no surprise the syntax is Java-like. I fully expect sometime soon to see a JVM implementation that will then leverage all the existing Java libraries.
In that context (IMHO) it makes a lot more sense. It might not be solving the problems you're interested in but it is definitely solving a particular set of problems.
If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.
This was advertised as a replacement for JavaScript. It turned out to be a replacement for GWT. False advertising. I'm wasting time reading specs and code samples and comments just to figure that out. I don't like being misled or wasting time.
Python has a great, clean, compact and expressive syntax and a lot of syntactic sugar. Erlang does concurrency and error handling well. A mix of the two would be a great language to work with.
Ah. I think I was getting caught up in the idea that a "replacement" was something completely different and not an evolution change in JavaScript. But it's all just a matter of terminology at that point.
A lot of people use GWT for large web applications instead of JS, precisely for the reasons Dart was created, we just don't go brag about it.
The biggest problem with GWT was how slow the toolchain was, and this is adressed with Dart by having a native VM in Chrome.
Out of curiosity, do you know of any notable non-Google sites using GWT? I see a few here, though none seem to be particularly large web apps - that I can tell, at least.
Given that its supported by Sencha (ExtGWT), and Spring, and IntelliJ, you can probably guess that the vast majority of GWT users are in enterprise environments. :) AngryBirds uses GWT. You actually don't see many people writing very large Web apps outside of Google precisely because most organizations didn't have the resources to produce something like Closure or GWT. Duplicating GMail with no tooling using basic JS is quite a tall order.
Many new Google services these days use GWT, like Google Flights, Hotels, the new YouTube editor, Google Offers, etc. AdWords is written in GWT too and is quite large (millions of lines)
One of the problems Dart hopes to solve is to have a large codebase(apps easily into the millions of lines of code) that is toolable, and statically optimizable. Javascript is particularly poor at this.
The Closure Compiler was actually invented by the Google Mail and Calendar teams as a way to wrangle Javascript and tame it's suckier bits to enable sane development of large apps.
IMHO, this is not a "break away" approach as originally indicated in the leaked memo.
One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.
The original leaked memo that everyone was freaking out about was incredibly overblown as it was entirely decontextualized.
The engineer that wrote the memo needed people for his team. To get people to join a team from any of the others at Google, you need to convince them that your team is awesome to work with. At Google, you can't offer more money/benefits, so it has to be a "join us and you'll change the world!" message. That's going to lead to a lot of overblown statements that may or may not end up being true, and may or may not even be believed by the author.
Google is not in the business of doing things that are bad for the web (and when they have done, there's been an about-face, see: Google Video shutdown), even if internal machinations might make it seem that way.
I'll stress that it's early days for Dart. Go was announced in 2007 and only this year is going to a version 1.0.
I don't know what the timeline is for Dart but I will say this:
1. If anyone is capable of the long sort of time frame that something like this can benefit from--event requires--it's Google;
2. If there is anyone who's qualified as a domain expert in Javascript generation it is, by virtue of GWT, Google; and
3. If there is anyone who's qualified to speak to the limits of what you can do with Javascript it is, by virtue of Chrome and V8, Google.
If anything, I believe the error here (if you can call it that) is failing to properly set expectations and communicate the goals of the language (as witnessed by all the comments on this thread from people who were expecting something more and/or different).
We are definitely trying to improve the DOM API with Dart, but, for performance reasons, ditching the DOM and starting over from scratch in Canvas doesn't really fly, at least not in the short term.
Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases.
Google has some incredibly large and ocmplex JS apps (eg GMail). While GMail isn't written in GWT, GWT is aimed at that kind of application with deferred binding and the benefits of static type analysis.
What if you took that expertise (of GWT and static type analysis in producing Javascript) to produce a language that could run on the server, run in the browser (for browsers that support that) and compile to Javascript (for browsers that don't)?
The last point is particular is key to driving adoption as no one is going to develop only for Chrome.
I see it as no surprise the syntax is Java-like. I fully expect sometime soon to see a JVM implementation that will then leverage all the existing Java libraries.
In that context (IMHO) it makes a lot more sense. It might not be solving the problems you're interested in but it is definitely solving a particular set of problems.