Performance is a design goal, but it is not given as the primary goal.
Of course, a cynical observer might say that the real primary goal of Dart is to give Chrome an artificial performance advantage over competing browsers, since that will be, at the very least, an initial effect if Google succeeds in promoting its adoption.
I think you're pretty naïve if you think that "Google doesn't care if Chrome is perceived as faster". That's been the entire thrust of their marketing, quite literally from day one.
As it stands today a Chrome user is no more valuable to Google than an IE user (well, apart from google being default search provider).
But any web user today is more valuable than a web user 3 years ago because the browsers deliver a much better experience now, causing the user to spend more time on the web.
Chrome played a major part in this development.
A chrome user is more valuable to google than another browser user:
google paid 1 billion dollars for a search deal to Mozilla with ~30% mkt share. If google had never built chrome, Mozilla share might be 50% or more today. The search deal would've been commensurately more expensive.
The point is, google doesn't have to pay for search engine placement for a chrome user.
"As it stands today a Chrome user is no more valuable to Google than an IE user (well, apart from google being default search provider)"
I'm not sure your caveat is needed -- on a new installation the first thing Chrome does is ask you what search provider you want to use, you're just as free to pick Bing as Google.
Chrome does this, but IE does not. That alone means that a much higher proportion of Chrome users will use Google than IE users. Then factor in the relative name recognition for the two search engines...
> (well, apart from google being default search provider)
That's a rather significant difference, you know.
But control over a given user's browser has incredible potential value for Google. Controlling both client and server means that you no longer have to sacrifice performance in the name of standards compliance (so long as you have a standards-compliant fallback mode for other browsers). What that means if you're Google is that a visitor using Chrome can 1) cost you fewer resources, and 2) walk away with a smoother, more satisfying experience.
Does Google currently take much advantage of this potential? I can't say for sure. But we are talking about a company that omits the </html> on its homepage in the name of performance.
Why would it be an "artificial" advantage? Chrome exists because Google wanted to push the web as a platform forward and encourage other browsers to evolve. That's what happened with Javascript and SPDY (_very_ rapidly with SPDY, it seems to me).
If Chrome is faster at running Dart it will only really matter if 1) Dart is also faster than Javascript and 2) Dart is better for building complex web apps. That would validate the "clean break" approach as an alternative to the evolution approach. I don't see what makes that "artificial".
If Google successfully gets people to adopt Dart, but other browsers rely on JS cross compilation while Chrome has a dedicated VM, then there will be a period during which Chrome has an artificial advantage. This is a virtual certainty.
Dart might also have real advantages, and those would be enjoyed by all once other browsers provided fast implementations. But initially, Chrome would enjoy an artificial advantage even if Dart was actually worse by design than JavaScript, so long as they could get a significant chunk of web developers to adopt it.
My point is that getting people to adopt a technology that your product pioneers confers on you a market advantage independent of the actual merits of that technology.
And yet, oddly, one of the front-page testimonials for node.js is LinkedIn saying that use of that particular brand of server-side Javascript gave them "huge performance gains". That obviously doesn't mean that Node (or Javascript in general) will perform well in every situation, but it does show at least an existence proof that JS is capable of high performance in some very demanding environments.
What I haven't seen out of the Dart project, so far, is a description of what performance targets they're trying to meet, why they think that no set Javascript extensions (e.g., the "freeze" proposals for Harmony) would suffice to meet those targets, and why they think that any of this is relevant to people whose needs _are_ adequately met by Javascript as it stands.
So your justification for Dart being unnecessary is that the Javascript interpreter built by the people who are building Dart is really fast (for a Javascript engine)?
Don't you think that building V8 (the engine inside Node) may have given them some very good insight into the upper bounds of Javascript performance and insight into ways to fix them?
If v8 is fast enough for anything that I might want to do with it, further performance improvements (as opposed to other changes) are not going to be really high on my wish list. That's why the performance case doesn't work for me.
Other people might have different tradeoffs, of course. Which is fine. But nothing I've seen the Dart crew say yet explains in plain English who those people might be, and why the particular set of tradeoffs in Dart is better for them than either v8 or, say, some other language reduced to strongly typed bytecode for PNaCl.
http://www.dartlang.org/docs/technical-overview/index.html#g...
Performance is a design goal, but it is not given as the primary goal.
Of course, a cynical observer might say that the real primary goal of Dart is to give Chrome an artificial performance advantage over competing browsers, since that will be, at the very least, an initial effect if Google succeeds in promoting its adoption.