Dart is a new language by Google with new syntax and new operators.
A language overview here:
http://www.dartlang.org/articles/idiomatic-dart/
Goals:
http://www.dartlang.org/docs/technical-overview/index.html#goals
| You will be able to run Dart code in several ways:
|
| Translate Dart code to JavaScript that can run in
| any modern browser: Chrome, Safari 5+, and
| Firefox 4+ (more browser support coming shortly).
That's quite a contradiction, but exactly what I would have expected
from Google. Don't even have to look at the code to know it's another
non-starter. They just can't get their collective brains around cross-
browser scripting.
What that should have said is:
"Works in Chrome (versions?), Safari 5+, FF 4+ and compatible browsers
and does *nothing* anywhere else."
The pattern is:-
if (hostfeatureworks) {
// create the wrapper
} else if (hostfeaturealternativeworks) {
// create alternate version wrapper
} else {
// do nothing!
}
Apps then detect the presence of the wrapper(s) with the damnable host
object details hidden behind the scenes. This allows old forks (e.g.
legacy IE BS) to be removed without breaking apps and add-ons. Seems
like a very simple proposition to me. If you are to abstract an
unknown environment, you have to account for the "none of the above"
cases. Host features come and go over the years, so there will always
be the chance of environments that can't run the app (or enhancements)
under any circumstances.
I've explained this concept to many developers (particularly JS
library authors) over the years and the number one answer as to why
they don't use this pattern is that they don't want to wrap their apps/
enhancements in an - if - statement. Of course, leaving off the
"gateway" won't break anything that isn't already broken. The only
difference is that the calling code will fail immediately on trying to
call a *library* method that doesn't exist (something easily remedied
with a gateway) rather than deep inside some ridiculous library.
So jQuery, Google, etc. all write code based on this pattern:-
if (hostfeatureworks) {
// create the wrapper
} else {
// create alternate wrapper come hell or high water (sometimes
impossible).
}
This is the "normalize at all costs because that's cool" pattern.
So have they made the situation for the calling app worse or better?
Clearly much worse as a potential impossibility has been glossed over
in the - else - fork. The calling app can't tell whether the features
it needs are available or not. In other words, short of digging into
the host objects themselves (what the library is supposed to be
hiding), apps based on such code are oblivious to their environment.
First call to a library method trying to use a host object that does
not exist blows up. Nothing to keep add-ons in line either.
The end result of this is jQuery and others still have lots of old
(and badly done) workarounds for legacy browsers (e.g. IE 6/7/8) with
no way to remove the code. I suppose they could take a poll of all
library developers and if a majority says IE 6/7 (for example) are
"irrelevant" (as they see it), then they can remove a ton of lousy old
code. But then the library-based sites that don't care to break in IE
6/7 are unable to "upgrade" and orphaned by the project.
So I don't see how Google replacing the *language* is going to help
anybody but Google. And if they are trying to take a leadership
position in cross-browser scripting, they've got a long (and seemingly
insurmountable) way to go. Their previous effort was based on Dojo for
God's sake.