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

Right, call me silly but I'm honoring the "Right-click->View Source" spirit here, I don't know about you but I feel more confortable knowing that my browser is downloading source code and compiling or interpreting than downloading some kind of binary to execute, even if you call it "intermediate code", "byte code" "almost-there-machine-code" or whatever, it's still binary stuff. I get your point though.

Responding to your comment about NaCl, I just wanted to point out something, not contradicting what you said, but emphasizing the motivation for the other side. We are right now in a situation where every significant browser innovation has to move through a very slow process on a timescale of years. And these are the succesful features not blocked by vendor politics. Also, features which are not of widespread interest, (say I want to try web programming in a new just invented language), dont even come up in discussion, due to limited resources of the standardization process. We would ideally want to be in the position similar to lisp where innovations even in fundamental areas like object systems dont have to wait for a committee before being used in production systems, as opposed to something like the Java standardization process.

Now, NaCl may not be ideal for the various reasons you list. But something similar to it, when it becomes standardized, will lead to much faster innovation. Things which were previously held up in standards committees can then happen on the fly. In the spirit of Scheme, browser standardization can progress not library by library, but by removing the obstacles which prevent programmers from implementing libraries themselves. For this reason, I submit, that this should be one of the important goals of a web browser implementor, and maybe even worth a few compromises(not compromising cross-platform standardization, of course - the single greatest thing about javascript is that it freed us from the win32 api).

This was the original intent (to have many languages supported by browsers; not necessarily a single VM with many languages). It just never really materialized. By the time the web was ready for bigger apps that needed more software, Javascript was Good Enough for the purpose, and munging other languages into the browser was too much effort. JavaScript grew up alongside HTML and the DOM, making it uniquely qualified for building applications around HTML and the DOM. I think it's telling that Google is building a new language rather than modifying an existing one (though it does appear to be inspired by other languages).

You set up a series of straw men based on nothing I wrote. I wrote "Then Dart could come to Ecma as a proposed spec with a single open source implementation."

Nowhere did I say a single word trying to corral Google into a non-evil, artificially held back (you imply) posture of offering only compile-to-JS, with no Dart VM in Chrome. Chrome ships all kinds of non-standard or proto-standard stuff.

Chrome can certainly ship Dart if it floats their boat, and if it is standards-bound, meaning Ecma TC39 bound, then I will not object categorically.

The issue is whether Dart is even a proto-standard, or more a modern VBScript. Get it?

"Now they're evil and anti-open-web?"

Half-right. You put the e-word in my mouth, but yes, some of Google's actions are anti-open-web.

Remember, I'm not the one throwing around slogans about "evil". Do you really need me to quote Uncle Ben in full? The relevant words from that quote are "power" and "responsibility". Google is acting like a monopoly power. Now, being a monopoly is not illegal or evil, it depends on actions. You bet I am objecting to proposed actions in the plan that leaked.

But whether these actions are evil, I leave to others. They are definitely disruptive to Google's standards effort in TC39. The open-standards-based web does not work by following anything like the game plan in the leaked memo.

"As to the MSFT analogy -- I've never heard of any intentions of driving competitors to implement ActiveX or VBScript."

This is not only ignorant, but naive.

We at Mozilla faced pressure to implement ActiveX and ship support for it, starting in the late '90s. Adam Lock did an implementation, still in our source tree (IIRC in chromium.org too). Without ActiveX, plugins were unscriptable until we at Mozilla founded the plugin-futures mailing list in 2004 and co-created NPRuntime with Apple, Adobe, and others.

Good thing we (meaning Netscape, then AOL, which was under pressure) didn't cave and ship ActiveX support or we would have been on a very long, high-speed treadmill, reverse-engineering hundreds of COM interfaces in IE. But see my earlier comment about the PKI story in parts of Asia.

That's the history. I believe that you don't need to know it in detail to game out how minority share browsers were stuck without a plugin API locked into MSCOM and Windows. Really, what were other browsers to do, without market power to get plugin vendors sinking more cost in a second plugin API? The old Netscape-1.1-era NPAPI did not include scriptability (JS debuted in Netscape 2).

Ok, maybe you did need to know some details, but I still think your use of "analogy" and "I've never heard" are naive.

As for VBScript, MSFT was absolutely trying to make that a de-facto standard, gunning against JS as de-facto standard from Netscape (yes, Netscape was a monopoly at first; not for long). GNU folks even offered to get on the VBScript treadmill and help Mosaic, Netscape, and other mid-'90s browsers support it. Good thing JS came out early enough to choke it off to a few microsoft.com sites.

"Would that ease the objections?"

More straw men. If you don't know what I meant by "consequentialist", look it up. I'm not going to play "how low can you go" if we don't agree on premises, specifically how open web standards are best made, what's wrong with the game plan in the leaked memo, and why monopoly power shouldn't be so eagerly abused.

Being open is nothing like (a) delayed, single-vendor-dominated source code release; (b) sweet-talking or arm-twisting with a big ad budget; (c) hedging one's standards commitments so heavily while tossing fragmentation grenades such as standardizable-only-by-market-power new language VMs into Chrome.

I agree with your conclusions, especially that it's telling what Google is not doing, but I have to object to your "This was the original intent" lede. Whose intent was that? Not Sun's in '95 or '96 with the JVM, which was all about Java. Certainly not Netscape's.

Multi-VM/multi-language beats multi-language-single-VM, indeed, but then you have problems such as the cross-heap cycle collection one I raised on this thread. No free lunch.

And anyway multi-language-single-VM was never any browser vendor's original intent. I had folks like John Ousterhout belatedly (early '96) pitching TCL, but smart enough to see that it wouldn't fly (John then tried pitching Tk for cross-platform widgets, but Netscape was already screwing up its platform -- no sale).

Mid-90s C-Python, TCL, Perl 4 then 5 -- none of these was ever intended to be wedged into any browser and kept up-to-date. Not by Netscape or Microsoft or any vendor of that era, and not in the 2000s either. MS put IE on skeleton crew maintenance. The Silverlight-era "DLR" (single VM for many languages) was much later and not browser-bound.