1. No worse a user experience in any browser;
2. A much better user experience in Chrome;
3. A much better developer experience;
4. A much better server-side platform than V8.
Of the four, #1 (a good enough Dart->JS) seems problematic. #2 may be bad for other browser vendors, but if it's good for users and programmers, why should I care? I see no virtue in a lowest common denominator. #3 and #4 are hardly objectionable. Only those who like them need bother.
I don't know how likely this win-win-win-win is, but here's why I'm indulging in the hope. These guys have been gods of fast dynamic VMs since Strongtalk. If Dart is their chance to build what they always wanted, but this time with 20 years of experience to draw on and the institutional support of a Google behind them... well, we have the chance of something insanely great. Greatness sets its own standard.
Comparisons to VBScript and Flash only kick in if what they come out with is lacklustre.
Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax.
But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space.
More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required.
This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost.
The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See
under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.
Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow?
The right comparison here in your success scenario may not be VBScript but ActiveX, except without the security issues ActiveX had. If ActiveX were required for use of gmail today, how would you feel about it? How would you have felt about it in 2002?
XHR was a good idea. Even choicer irony: MS exposed it to JScript when they gave Java the boot, to keep Outlook Web Access working!
You say XHR was a good idea, and it's clear now that reverse engineering it and putting it into Mozilla's browser was a good move because it allowed that technology to advance the web -- but at the same time you are showing opposition to taking a similar course of action for a Dart VM because it's not an open standard.
In contrast, Dart usage in Google web properties targeting the native VM in Chrome, per the leaked memo, would pressure other browsers to adopt or reverse-engineer a much more complex non-standard.
I like Apple's hardware (modulo the fans running all the time on my latest dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on Lion?).
Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took hard, open-standards spec-work in the CSS WG. And that, to the extent it happened with help from Apple, is the opposite of the Dart plan in the leaked memo.
Stop worshipping i.g. It's never that great. Native apps on iOS use Objective-C, for crying out loud. Everyone's sh*t stinks.
I.g. is no excuse for monopoly behavior. The greatness goes away, leaving only insanity.
Like I said in a tweet this morning, I know those Googlers know way more about JS than I do, but if they think as per the leaked mail) that devs are choosing iOS over browsers because of JS, they have their heads in the sand.
Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform like you guys are doing with B2G and they started to do with ChromeOS.
For example, I'd love to hear from the ChromeOS team exactly what in JS is blocking them delivering all the kinds of APIs that B2G is promising to deliver.
And on the server-side, some one should tell the hordes flocking to Nodejs that they are all wrong! As you pointed out, serverside everyone can choose to use whatever they want and given that choice, just look at everyone jumping on the Nodejs bandwagon. I'd love to see all those thousands of module that dev around the world have written in Go recently! (npmjs.org)
I think we have some fundamental philosophical differences about how the world should work. ;)
Of course I don't think that. I meant by "ubiquitous" to imply the opposite. I fear we're talking past each other.
The risks of Google behaving like a Microsoft-style monopolist here are low because (a) they have no monopoly in browsers, VMs, or OSes to abuse, (b) their culture is the most hacker-driven of any large company, (c) their interests are aligned with what is good for the web, and (d) the industry has changed since the bad old days.
Given this, and because the potential value of this project is so high, I'm willing to give them a chance.
I admit the odds are against it turning out so well. But this is the rare case where at least some optimism is well-grounded. If what they release does turn out to be an attempt at the above, it will be exciting.
With ActiveX, the interfaces that might be used are too many, and their implementations too large and complicated, to have bug for bug compatibility. Even having source code would not be enough. All-paths testing would be needed.
Someone could (and a few companies did, for COM on Unix) tediously reverse-engineer a subset of COM interfaces and components implementing them. No one ever pulled off anywhere near a full Windows workalike.
The same threat arises with delayed-open-source controlled by a single proprietor. You can port and fork such code, but you can't depend on the single proprietor, especially if it's a hostile competitor. You'll have to co-maintain if you don't make a long-term fork of your own.
Source != spec. An implementation will over-specify in its source code and API. Abstractions leak. Standards can and do turn down specificity by dropping to prose or more formal means, without overspecifying.
"The risks of Google behaving like a Microsoft-style monopolist here are low because (a) they have no monopoly in browsers, VMs, or OSes to abuse,"
Look closer: Google is a search monopoly in many locales, and they are an emerging duopoly member (the larger share than Apple) on mobile, whose growth predicts it dominating desktop.
"(b) their culture is the most hacker-driven of any large company"
That was true a few years ago. It is much less so now. Larry has cut back on the thousand flowers, and focused on a few strategic bets: Android, Chrome, Google+, Search.
"(c) their interests are aligned with what is good for the web,"
So you say (and perhaps Google people say this, but I know some who candidly admit it just ain't so any longer).
Why do you believe this? As a public company, Google has to show quarterly good results, not just great profit margins but bubbly growth, to keep its stock appreciating, to retain and recruit (see the Facebook defection problem of last year). This is a big distortion on a pure open web mission.
"and (d) the industry has changed since the bad old days."
And human nature has changed since the 20th century, or the French Revolution, or the dark ages? Yeah, right.
In that case, I have no idea how you think ActiveX could ever have become "ubiquitous".
> they have no monopoly in browsers, VMs, or OSes to abuse
They have a monopoly in search engines (and some would argue webmail clients), and are trying hard to work on browsers and OSes, especially on mobile... Give them a few more years, and see how things look.
> their interests are aligned with what is good for the web
They used to be, for a bit. At this point, I've very skeptical that this is still true.
> the industry has changed since the bad old days
Has it? I don't see much evidence of this. Particular _markets_ have changed, but attitudes really haven't.
You know what, scratch everything I said about ActiveX. I didn't think about it very much (it was so awful, I can't bear to), and you're probably right.
< I don't see much evidence of this. >
Really? To my mind the industry is more hacker-centric than it used to be. For example, there's a spectrum of how open and sharing Google may turn out to be with Dart. Some points on that spectrum are better than others, but nowhere on it is the possibility of an old-school closed-source implementation. That's a major change from how things used to be.
The two technical/cultural shifts, open source and the open web, make for a good trend.
That's why counter-trend action such as delayed-open (Dart), delayed/partly-open (Android, e.g., but other examples are easy to find) raise hackers' hackles. At least for some hackers.
And hackers aside, the competing vendors meeting in existing standards bodies get left out. That clouds the prospects for future standardization, unless (again) based on market power. Which is not there, if the topic is Google Dart (and it is :-|).