Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

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.

Also, try to pay attention to the historical correlation of market forces: XHR came in when Microsoft was a monopoly:

http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp...

Even then, it was new and optional, and we cloned it into Mozilla (Opera cloned it too). It was pretty simple compared to anything like Dart or NaCl's Pepper APIs.

Ok, look where we are today: no monopoly power, but Google arguably acting like one. That won't lead to reverse-engineering without a much less balanced market.

First, the reverse-engineering costs of Dart are much higher than of XHR.

Second, the more balanced competition won't make any browser follow instead of lead. We could indeed end up with two problems (three, counting JS), as just happened with WebSQL and IndexedDB. Dart, and Microsoft's new language Phart, say. :-P

Glib "shoot first, ask standards bodies later" is a recipe for fragmentation and non-interoperation. Even if standards are written (years later, for XHR; never for VBScript and ActiveX and a great many examples you conveniently ignore), they don't offset the up front costs.

And here's the kicker: if you get your wish, there won't be one interoperable superior language ruling the roost until that later standardization step, if it even happens. If there's no monopoly or duopoly power structure, you'll just have the "inferior" language (JS) and spotty support for the "superior" one.

It seems to me that a lot of you "bring on our new overlords" boosters are unaware of how HTML5 came about. It was not through one vendor shipping proprietary code and standards bodies mopping up later. Study some recent history.

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.

I understand the viewpoint that you would rather have had Google focused on improving JavaScript through Ecma TC39 than creating another language with absolutely no outside influence. I also admit that this is a pretty inconsiderate move for them to make, especially as that email made it sound as this new language aimed to be a "replacement" for JS. But despite the lack of good will behind this action, I would still hate to see something as rare as a new client side language, that has a decent potential of allowing developers to think differently about solving problems on the web, die off because no one wanted to adopt it.

The "dynamic-hashes" remark shows serious ignorance of polymorphic inline caches and shapes aka hidden classes. Competitive JS JITs do not probe hashtables for dot member accesses.