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.
Open source is usable only by some vendors. My Opera pals say they can use it (I'd heard differently from others at Opera in the past). Microsoft, I'm told, cannot -- they cannot even read open source. This is public knowledge, it came out, e.g., as part of the IronPython project.
So Microsoft objected to WebSQL, since it depended on SQLite as source-code-is-specification. Writing a spec for SQLite or Dart is very hard. SQLite is >100KLOC in one .c file! Dart is at a guess bigger. Hence, reverse-engineering is required.
Reading code at this scale doesn't tell you enough. Testing, with good coverage, is required. Then you have to separate the over-specification due to abstraction leaks and bugs, from the intentional specification. That's hard work too, and while source code comments may provide clues, the source itself does not say what's what.
"Well shit. I definitely don't want to be one of those!"
Sorry, I was not addressing you specifically, rather the (many, more than I expected) people here and elsewhere who are asking for the new and good monopoly to rewrite the web by itself with more awesome languages.
The IE monopoly with ActiveX and all that was so long ago, the new generation did not live through it.
I certainly remember and that's what your comment made me think of. It's not QUITE the same thing as it is supposed to compile to js but yeah, I get the comparison and would prefer to have no single-corporation overlords.
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.