Yes, standards must keep up, whatever the proprietary challenger does -- this was true when Flash could do many tricks that browsers generally could not.
Without further nuance, saying "standards must keep up, deal with it" is a bit too consequentialist for me, a Mozilla founder, or for anyone working sincerely in the open web standards bodies. Korean and Chinese banks still require ActiveX PKI plugins or else deny service. The end of better web tech does not justify any means, especially not single-vendor locked-in means.
It seems to me Google is trying to have it both ways, which creates not just the appearance of a conflict, but an actual conflict: does their top talent work with standards bodies to make interoperable specs (based on prototypes and open source and so on), or do they go for wow-effect and sweet-talk if not strong-arm tactics?
Google knows they can't standardize something like NaCl. My belief is that control flow integrity enforcement will sooner come to OSes and OS-targeted toolchains than it will to browsers via NaCl and Pepper. So, safer (but still OS-specific) binary plugins, in the next five years. But mapping Pepper, an unimpressively large and messy API tied to Chrome as well as WebKit, onto other browsers? Other vendors won't get on that treadmill, and I don't believe Google would try to "do it for them". Gears was too painful.
On Dart: Google as a single entity does not know what could be done in Ecma TC39, since the Dart/V8 principals never participated, and V8 needed a fresh-thinking second team finally to get going on Harmony prototyping. But let's agree that one or two designers work better sprinting alone, not burdened by a committee (see my blog post for how we avoid design by committee).
Then Dart could come to Ecma as a proposed spec with a single open source implementation, perhaps later this year or early next. This was not part of the leaked game-plan, however. Clearly Google did not, as of that document's date, intend to standardize. And who believes they would give up "design control"?
Would TC39 entertain Dart as a second language? I doubt it. A whole second spec to write and get through ISO, cross-language-heap cycles to collect, mixed and possibly conflicting runtime semantics, specifically more numeric types in Dart than current JS to coerce and/or fail to convert in the native/managed bridges and API stubs, the list goes on.
Would TC39 take inspiration from Dart and fold ideas and design elements into the Harmony agenda? Absolutely we would, but we need to see Dart first, and this last week does not make for an auspicious launch. Still, no hard feelings if we do get a clean pitch from Dart principals to TC39.
However this plays out, Google has a lot of power. I won't quote Spider-Man's Uncle Ben, but for a company that moralizes about evil-as-in-don't-be, the standards they hold themselves to have to be high. I argue that they can't successfully and faithfully both work for interoperable and better web standards among multiple browsers, and play deep proprietary lock-in games. Pick one or the other.
Innovating in the open and proposing early and often to standards bodies are fine. Delayed-open-washing and increasing piles of proprietary (open-source doesn't matter) single-vendor code, which implements features that are not ever proposed for standardization, are not.
Even if any means are justified toward the end of improving web programmer productivity over what JS affords today, Dart represents a specific, clear and negative judgment on the Harmony work in Ecma, a judgment that I believe will be shown to be a mistake. It can't possibly help us make faster progress in TC39 -- it's at best a distraction and at worst a break in trust among the members.
With tooling (Brightly) and massive developer and evangelism resources backing Dart, will we really have the kind of open-web-first, fair-play contest that people who thought Google was (as Paul Graham put it) "aligned with the grain of the web" have come to want and expect from Google?
It looks like we won't. GOOG is acting more like MSFT of old (also like AOL, wanting sticky eyeballs and time-on-site instead of being the best search engine). The game theories of public companies, the innovator's dilemma, the Facebook challenge, and the browser-vendor Prisoner's Dilemma, all predict this ironic development. It is not a surprise.
But companies are made of people, and I have hopes that Googlers on the right side of this conflict will speak up.
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).
First, jashkenas isn't held up by standards committees -- he's able to experiment with cool new client-side web tech on whatever schedule he wants. And building on this, even more new stuff is happening, like Tim Disney's contracts.coffee [1].
Second, your ability to ship the coolest new client-side technology isn't being held up by TC39, or by the HTMLWG -- nothing we or they could do would make MS ship IE 9 for XP (or make people upgrade from Debian Stable :).
Third, the reason that design takes a while is because it's hard. I'm really glad that Dave Herman and I haven't iterated the ES6 module design in shipping versions of a browser -- that's not the right thing for anyone.
Finally, you mention Scheme. If you want to see a truly disastrous example of language progress held up by politics, check out the last 5 years of Scheme standardization.
I guess I was wrong when I said every browser innovation. I also, more or less, agree with your other points - my goal wasn't to bash HTMLWG but to point out that the standardization of a lower level api will help us skip some of the other parts of the standards process by allowing us to do things like compile an sql library directly. Design is indeed hard, but with people free to implement different alternatives, it can happen in a distributed way with more possibilities explored even in production systems. Of course, something as basic as a module system should definitely have a standard. Which would also lead me to agree with your comment on scheme standardization while noting that some of the experiments with first class environments and f-expressions seem to be a genuine exploration a new part of the design space and not a gratuitous incompatibility, but maybe the standardization process should ignore them for the time being.
Quick comment: lower-level APIs can be harder to standardize than higher-level ones, depending on the diameter of the API-set and the implementation dependencies. Running native binaries requires a new compiler and a bunch of runtime API support (Pepper).
OTOH adding typed arrays or binary data to JS is narrowly targeted and pays off for higher-level API builders. And the typed arrays and binary data specs are being standardized.
You have me wrong: NaCl is great, perhaps as near to ideal as it can be (it's still nowhere near "done"; it's experimental where it isn't in DLL hell, libc hell, "portable" LLVM bitcode hell, etc.).
The quality of the NaCl work is not the problem.
The problem is that none of the other browser vendors can or will afford to get on Google's treadmill, trust Google as much as they would have to, then try to implement Pepper (for which the code is the spec, including bug for bug compat), take on all the toolchain dependencies, and hire people to co-maintain on their own release schedules. Not gonna happen.
The OS-specific toolchain-and-runtime alternative looks likelier to me. It solves the distribution problem, sinks the costs at the OS vendors, and avoids requiring coordination at the price of the safe plugins still being OS-specific binaries (which we live with today).
Another problem I have with your comment is the hope that innovation speeds up when we have more native-code plugin options. I doubt that greatly.
Web developers can choose different tools today, but their complexity is mostly confined to the server side and to the development lifecycle there.
Moving some or all of this complexity to the browsers via a large and growing menu of "DLLs" that are required to be downloaded along with primary app source? No way. Remember, the whole gambit of NaCl requires the humongous and messy Pepper API, the API that is nowhere near standardized or ready (or able) to be standardized, which non-chromium.org browsers are not going to support.
It's like the >1000 MS-COM interfaces that ActiveX plugins can and do use in old IE versions.
My bet is that the client side will not grow to look like your random Apache installation with (magically memory- and control-flow-safe) multiple programming language DLLs lying about. We may get to a post-JS future but it won't be that Tower of Babel, not on the client -- especially not on the mobile client.
I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role.
Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming language and the ability to compile to a reasonably low level target for performance while still being cross-platform. Now, this somehow needs to be done without the security nightmares of ActiveX plugins. (Though, I dont see the non-security problems with a bunch of shared libraries stored on the browser. This is essentially what the OS does, and my goal is to replace the OS with the browser. Bandwidth will probably improve so that downloading libraries shouldn't be a problem and if not, the web site maintainer can still choose not to develop in a large library environment The popular ones will be cached in any case.)
You seem to be saying that the technical difficulties of doing this in a well-specified (memory and control-flow), secure and cross-platform way are intractable. Maybe this can be solved by moving the VM to a more abstract level.
I don't know how to be more clear. I'm not talking about the technical difficulties by themselves, out of context. The technical difficulties are formidable -- but not insuperable for Google with its many engineers.
I'm saying that in context of market realities, the other browsers won't use shared Google-source as the "implementation is the specification" for NaCl/Pepper, and no one can write a real NaCl/Pepper spec by which any browser could implement an independent and interoperable workalike in less than decades.
So why try if the OSes can do their own non-interoperating workalikes? (And they are already doing this, from what I hear.) If safe native code on the web is mainly for plugins, there's no problem. Plugins are OS-specific today and likely to remain so, safety or no.
OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.
In the very long run, could OS-specific CFI enforcement toolchains and runtimes merge into a single standard, usable on the web?
Maybe, but that is beyond my prediction horizon. Either OS vendors or browser vendors (if there's a difference) would have to standardize a butt-load of APIs.
Since the '60s, researchers have dreamed of universal object files (ANDF, e.g.). It would be too funny if far-future JS merges into this single standard too!
("too funny" in my experience means this will definitely happen...)
I'm having a hard time understanding these objections.
Suppose Dart is a new open-source language from Google for front-end web developers. Surely this wouldn't offend anyone.
Now suppose they include a Dart->Javascript compiler with the language. Well, he have GWT and coffeescript and all the others. Surely this wouldn't be offensive. Pragmatic, even.
Then, being in the unique position to do so, they include specialized runtime support in Chrome (and it will still compile to JS). Now they're evil and anti-open-web?
As to the MSFT analogy -- I've never heard of any intentions of driving competitors to implement ActiveX or VBScript.
Still, I'm curious, if Google, responding to reactions such as this one, said "our bad, it won't run any faster in Chrome. See you at the committee."
and released the JS compiler only. Would that ease the objections?
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.
A bit more detail about ActiveX. What really brought pressure on non-IE browsers targeting Windows was not just ActiveX's support for scripting the plugin from the page's JS -- again that was missing from the NPAPI.
Fast forward to today. I'm told that the next Android release, Ice Cream Sandwich, will drop NPAPI support -- this time in favor of Pepper. ActiveX, ActiveG.
Vertical lock-in from plugin to browser to OS to hardware. The 90s -- if not the 80s pre-commodity-PC -- are back.
I think you are being unfair in your criticism. Microsoft, Apple, and Adobe, just to name a few, have all tried to force web developers into proprietary closed-source platforms. If you want to get angry, get angry at them!
Google is just trying to give web developers a choice. They plan to continue fully supporting ECMA's efforts as well, with developers and money. And for this they deserve to be attacked?
You keep talking about lock-in, but if Dart becomes popular, other vendors will integrate it into their browsers as well. That's what being an open standard means. There's no lock-in here (assuming that my understanding of the project is correct.) Let's try not to be petty about, even if JS is your baby.
What makes you think I have not been "angry" at MS, Apple, and Adobe? You must not follow my writings closely!
What's more, my mood is not the point, actual market-facing behavior is.
The topic here is Google and its actions. There are good reasons to focus on the big G now:
* Microsoft is older, formidable but late to mobile, in some ways in decline.
* Apple, we know what we get: proprietary lock-in -- but also extensions to the web platform that mostly (still waiting for some CSS spec drafts) get into the web platform. The secret sauce is the iOS-specific stuff: Obj-C, Cocoa, CoreAnimation, etc. They do not cross the streams.
* Adobe has turned to HTML5. They know Flash is in trouble. Neither Flash nor Silverlight is the "open web" threat some of us worried about four or five years ago.
In contrast, Google is a money machine with significant market power, and it is crossing the proprietary extension and open web standards streams without doing the requisite open spec work -- yet, of course. But very late spec'ing is no help. And again, open-washed open source is not nearly enough.
"Google is just trying to give web developers a choice. They plan to continue fully supporting ECMA's efforts as well, with developers and money. And for this they deserve to be attacked?"
From the http://wiki.ecmascript.org/ recent changes history, you can see who is doing hard work on Ecma proposals. Mark Miller works very hard. Google as a whole does not, and it could do a lot more, but it is not of one mind, and it wants to try both proprietary and open-standards tracks.
My point is that doing both means doing one well and one poorly. Can't serve two masters.
As for "just trying to give web developers choice", grow up. How would it work if Mozilla, Apple, Microsoft, and Opera revealed delayed-open-(spec|source) new and non-interoperable programming languages to "replace JavaScript"? Uh huh. Now can you spell "fragmentation"?
"You keep talking about lock-in, but if Dart becomes popular, other vendors will integrate it into their browsers as well."
Dart is a secret still, hence "proprietary". Delayed release of source and/or spec won't make an open standard that multiple vendors will implement, hence "lock in".
Without monopoly or majority market power, Google cannot force other vendors to support Dart in the short run, and the lock-in effects of having two+ years head start designing and implementing Dart is a negative for other vendors.
Even if Dart becomes so popular via either a native VM in Chrome or Dart-to-JS compilation elsewhere, other vendors may defect and not implement native Dart support.
Unless Google has high Chrome share by then on its web apps and sites that use Dart, it will suffer poor performance in the JS-implemented runtime the Dart-to-JS compiler targets, and may have to come up with a "plan B" (use pure JS, try a Gears-like plugin, etc.).
Meanwhile, JS is growing ever faster and the standardized ECMA-262 language is being evolved. And other vendors may try their own tit-for-tat proprietary responses (Mozilla won't).
"That's what being an open standard means."
Bullshit. I work on open standards, I've done it for 15 years. Have you? Open means Open: no wow-effect reveal after two+ years work, no promises (empty in a lot of cases so far) to standardize later.
Yes, Netscape didn't do that. They were a monopoly. I'm not moralizing here, I'm pointing out that because Google is not a monopoly, it can't help but fragment the web by acting as if it were.
"Let's try not to be petty about, even if JS is your baby."
You misunderstand me. JS is part of a "commons" now, not my baby. It's a shared asset. It requires stewardship, including evolution, and not just maintenance.
The leaked memo declares that JS can't be evolved to fix critical problems, in order to justify Dart, without giving evidence and without Google making a concerted effort in the governing standards body, Ecma TC39.
My concern about this two-faced and fragmenting approach is not "petty" and it's not about "my" anything.
It's about a common good ethos that must prevail or the open web tends to fragment. Not all at once, not fatally, but down a bad and slippery slope.
Just a small historical revision - Netscape was losing a point of market share per month in mid 1997 - even before IE4 came out, because of Microsoft enforcing IE as the OEM browser on most desktop PCs
I cited some market share links from wikipedia elsewhere in this thread, and TechnicalBonobo set me straight on monopoly vs. (let's say) dominant competitor or market leader (whatever that term is).
The point for Dart (vs. JS) is that Google doesn't have 80% or even 50% share.
Those of us old enough to remember (Brendan, that should include you) know that Javascript itself was developed by a company (Netscape) in pretty much exactly the same way, for pretty much exactly the same reasons. Get off your high horse...
If you are that old, you really ought to have better reading comprehension. My argument has nothing to do with Netscape, me, or my high horse.
Look, Netscape had a monopoly and put JS "on first" and just about everywhere. I'm done apologizing for that, I've made up for it in spades on standards work, and it's a fact I cannot recall and rewrite.
The precise point now, here on planet earth and not wherever you are, is that Google is not that new monopoly. Not yet, not likely for years even in their wildest dreams.
If Google were the monopoly Netscape was, sure: Dart would be the new JS. The two would co-exist for a long while but "replacement" would be conceivable so long as market power held up.
Since Google does not have monopoly power, and with the non-standardizing tactics of that leaked memo, Dart is unlikely to be adopted by other browsers. It's fragmenting. It's an invitation to others to inject their own would-be replacements and build a Tower of Babel.
"I'm done apologizing for that, I've made up for it in spades on standards work, and it's a fact I cannot recall and rewrite."
Wouldn't it be fair then to at least give Google the chance to do that standards work with Dart after it's released before labeling the company anti-open?
How early should a language be announced? It's certainly not cool to drop it on the world when it's done and baked , solicit zero feedback, and then demand the rest of the world implement it. But it's also not cool to toss out some vaporware spec with no implementation and no empirical evidence that the language is any good.
Look at what's actually happened, never mind the future:
1. Dart development (Dash, whatever, and there may be more, including CSS and HTML killers; not sure, rumors swirl) has been ongoing for approximately 2 years -- or more. It didn't start last November.
2. Google members of Ecma TC39 have been working on ES.next (some harder than others, I observe) without being able to show how Dart solves "unfixable" JS problems. Such demonstrations would help either:
2a. steer JS toward fixes if the "unfixable" assertion is false (as seems likely to me; little is unfixable on the web), or else:
2b. abandon doomed fix-the-unfixable attempts and instead work harder on other and fixable problems (e.g. being a better target language for Dart-to-JS compilation).
3. Delayed open-source means other browser vendors and volunteers have a high hill to climb to become committers/reviewers/co-owners, so Google controls the open source. This has happened many times. Competitors are unlikely to join, especially if the code is complex and has deep dependencies on other code (cf. NaCl/Pepper).
BTW, WebKit is an example more than a counter-example. It was Apple-dominated even though early-mostly-open, and now Google has taxed Apple committers/reviewers and is gaining the upper hand.
WebKit was early-open, a fork of KHTML at first, then set up as webkit.org in 2005 patterned after mozilla.org and in the aftermath of a recruit-half-the-Safari-team-to-fork-Firefox attempt by Flock. This history shows more open that closed, and earlier open at that, but mixed up with various intrigues and corporate control agendas.
While the history is not a clean win for any point of view, WebKit is a "commons" of its own. Note how chromium.org has to hold the Google-only extensions that Apple et al. won't take.
4. Standardization of Dart could happen anywhere, but it would be perceived as anywhere from wasteful to hostile for Google to bypass Ecma TC39. Early opening of a draft spec or even just an open-source implementation again could have won friends and influenced people on TC39. Late opening goes the other way.
What actually has happened, from what we already know: late-open.
My point isn't that you should apologize -- why should you? Any more than Sun should apologize for Java, or Microsoft for .NET Sometimes shit needs to get done, and people need to make things happen. Google is trying to fix some problems; no big deal. You see "Tower of Babel", I see the free market offering alternatives.
And don't be so quick to dismiss the likelihood of other browsers adopting Dart... If I'm not mistaken, IE supports Javascript, right?
Let's argue languages based on technical merits, not how or by whom they were developed.
"Javascript itself was developed by a company (Netscape) in pretty much exactly the same way, for pretty much exactly the same reasons."
That's wrong on at least two counts:
1. ["same way"] Netscape had a monopoly, it wasn't injecting JS into a situation where there was already a scripting language widely used on the web and implemented among multiple competing browsers. It was not fragmenting a multi-lateral browser market or web content language ecosystem.
2. ["same reasons"] The Dart reasons adduced in the leaked memo are nothing like our reasons at Netscape for doing JS. We (marca and I, mostly) wanted a language for non-Java programmers, non-programmers even, which could be written directly in HTML. A language designers, beginners, amateurs could learn by the yard. We did that without failing to upgrade a prior such language already widely supported.
Dart, according to the leaked memo, aims to replace JS because JS can't be fixed. But who says JS can't be fixed? Why, the people making Dart, working at the dominant web company of the last decade! That's no "reason", it is a choice.
"I see the free market offering alternatives."
Uh huh. If Dart has native support only in Chrome, then it's not an alternative for people using other browsers. Then what?
The "free market" is a bogus political phrase. I'm in favor of markets: real ones that self-regulate by preventing fraud (a central clearing/blinding counter-party, bid/offer/open-interest/size transparency) and abuse of power (market winners capture governments -- this has happened throughout history, it's a big problem right now, see the Global Financial Crisis).
Talking about Google's anti-standards power games in the current multi-lateral browser market as if it's all "free market" goodness is b.s.
"If I'm not mistaken, IE supports Javascript, right?"
Think, floppybunny, think! IE supports JS because Netscape had a monopoly once it took over from Mosaic and grew the web via commercialization (SSL, another Netscape innovation). IE had no choice but to support "JScript", and indeed they were thus motivated to help standardize ES1. Standards, hmm.
Google has no such monopoly. The likely outcome of putting a native Dart VM into Chrome and (again per the leaked memo) using Dart for web app development in Google is not to make other browsers roll over and embed the native Dart VM as well.
Can you see Apple doing that? Microsoft? Mozilla would be expected to do it by all you bring-on-the-new-monopoly fanboys, but even if we did it wouldn't help.
We're in a multi-browser market. Competitors try (some harder than others, pace Alex Russell's latest blog post) to work together in standards bodies. This does not necessarily mean everything takes too long (Dart didn't take a month or a year -- it has been going longer than that, in secret).
Open standards development does not mean design-by-committee, either. Multi-browser collaboration among Apple, Mozilla, and Opera was what created HTML5.
Dart goes the wrong way and is likely to bounce off other browsers. It is therefore anti-open-web in my book. "The end justifies the means" slaves will say "but but but it'll eventually force things to get better". Maybe it will, but at high cost. More likely, it won't, and we'll have two problems (Dart and JS).
"Let's argue languages based on technical merits, not how or by whom they were developed."
Now that's just low. You know damn well that Google has kept Dart a secret, so none of us can assess its technical merit (maybe you work for Google and can?).
Sure, when Dart is released, let's argue in a new thread. This thread is about the fragmenting, essentially two-faced politics of the leaked JS strategy memo, and whether and why that's bad for the web.
If you want a new monopoly to sweep the web clean, bully for you. No such monopoly exists now, so realists will still have to work in standards bodies. Is Google really working in standards bodies? As Maciej Stachowiak points out in this thread and over on reddit, more and more of their extensions in Chrome are not being standardized, and apparently won't be proposed "later".
In theory, you could have gotten input from Microsoft, IBM, Mosaic, and so forth before ever releasing Javascript. Did you? No. Even assuming that those other companies had an insignificant share of the market, and could safely be ignored, you still could have asked for public commentary on your design, like you're asking Google to do now. Did you? No again. It's hypocritical to blast Google for doing the exact same things you did, for the exact same reasons.
Secondly, every attempt to create a "programming language for non-programmers" has resulted in something horrible. According to wikipedia, "one of the design goals of COBOL was that non-programmers—managers, supervisors, and users—could read and understand the code. This is why COBOL has an English-like syntax and structural elements." When you are comparing your language design decisions to those made by COBOL, it is time to give up.
Your own stated rationale for getting Javascript done in 10 days was to "prevent something worse" from happening. This is the exact same reason why Google is developing Dart. The only difference is that for them, "something worse" is Microsoft Silverlight, Adobe Flash, and Apple iPhone applications.
Right now, if I want an application that "feels native," Javascript is a no-go, and I have to use one of these (closed, proprietary) technologies. Shouldn't we be saluting Google for trying to make the situation better, rather than blasting them for not asking their competitors for a mother-may-I?
Dart is going to be an open platform that is well-supported by Chrome and Android. That alone should be enough to make it a viable choice. It's great that you created Javascript and that it became an open platform for everyone. Now someone is trying to build something even better. You should be helping them rather than raising objections which are illogical at best, and hypocritical at worst.
First of all, you did not cite market share numbers to show lack of an effective monopoly. You cited a fun wall chart of all the various browsers, most with tiny and non-growing if not rapidly shrinking market share back in 1995. Come on!
Anyone around in the Netscape era knows that Netscape took over most of the market from Mosaic and smaller-share browsers, and evolved the web rapidly with proprietary (in the same sense I use against Google, however standardized later) extensions.
This led to Bill Gates' famous memo about the Internet Tidal Wave, and his cancellation of Microsoft's 1994-era AOL-killer, Project Blackbird.
Netscape dominated browser market share until IE came up to version 4, which was better on Windows than Netscape's old version 3 or very late version 4, and IE was bundled and locked-in hard to boot.
"It's hypocritical to blast Google ...."
Accusing me of hypocrisy shows ignorance of that word's definition in light of the history of my career.
I'm not practicing one thing and preaching another. I worked on JS standardization less than a year after shipping it in Netscape 2 beta. After that I co-founded mozilla.org. I'm not currently doing A and preaching not-A, nor have I been doing "proprietary" work for a long time. I've paid my dues.
Just FYI, like I owe you any explanations, Netscape did collaborate with Sun, gaining the "JavaScript" trademark license (a marketing scam, of course; I hated it). And I did collaborate with Bill Joy of Sun. But really, that's irrelevant.
Netscape was a monopoly in effect (it's very rare for a real-world monopoly to have 100% of the market). We did not have ability or time to make open standards of all our work. We knew, because Netscape had rejected a low-ball acquisition offer from Microsoft in late 1994, that Microsoft was coming after us. And we knew they had the power to kill us.
If we had not pushed hard to add programmability to the web (JS and Java in Netscape 2, plugins before in 1.1), then Microsoft would have been the reigning monopoly power, and would have abused that power (which did happen; it was prosecuted successfully).
So, though it's no justification in general, Netscape -- including my JS work -- did forestall a likely Microsoft push of their tech -- including VB as the Web scripting language. Monopoly good-cop/bad-cop act, or just history now, neither all "good" nor all "bad".
This is in contrast to today, where there is no browser monopoly and the top three have very close shares in many locales -- especially if you sort by model as well as make, and include WebKit variations on mobile, which is rising to eclipse desktop.
"Dart is going to be an open platform that is well-supported by Chrome and Android."
I think your sock-puppet is slipping. How do you know this? Do you work for Google?
Nice HN history you have, btw (two comments, both on this thread today). Why not do as on Google+ and use your real name? I have.
"1. ["same way"] Netscape had a monopoly, it wasn't injecting JS into a situation where there was already a scripting language widely used on the web and implemented among multiple competing browsers. It was not fragmenting a multi-lateral browser market or web content language ecosystem..."
"First of all, you did not cite market share numbers to show lack of an effective monopoly..."
"Netscape was a monopoly in effect (it's very rare for a real-world monopoly to have 100% of the market)..."
I don't think you know what the word monopoly means. Market-share is entirely irrelevant. What constitutes the definition (the reason the term even exists: what is meant to describe) is not how "big" a company is, but the _exclusivity_ (as in: is anyone else allowed to ENTER that sector of the market). And using the words "effective monopoly" or "in practice/real world" doesn't work as a permission to misuse the term, either. In fact, it does the opposite. Actual real-world "effective" monopolies would be: An entity holding a patent for some invention, the State having exclusive control of force, etc, etc.
Some company being "the only company who is currently doing X" is not a monopoly, as long as anyone else can enter the market.
BTW many of us developers are totally against the evil "effective monopoly" (see what I did there :P) that this not-so-pretty JavaScript language has in the world of web development, so the idea of more options doesn't sound bad at all.
Because last time I checked, there was no axiomatic law embedded in the fabric of the universe which stated that "Every desired improvement and/or business endeavor in the realm of browser scripting should be expressed in the form of a proposal for a next version of JavaScript, over at http://wiki.ecmascript.org, or else the oh-so-heavenly multilateral dimension of the interweb net will fragment and spiral down eventually collapsing into a black hole made of kittens"
Dart is probably going to suck, though (and Java-stained ideas polluting its design will probably be the cause). Also, unless Chrome wants to commit suicide, it's gonna keep supporting JS in the current and future versions, so you JS people should put a halt to this soap opera. Pause thy bitchfest.
I defer to your economic terminology expertise, but Netscape did have 80% of the market during a huge growth phase (people extrapolated exponential growth from a few months or quarters in '95 and '96). What's the term for that position?
Whatever you call it, if Google had that now or very soon, it could indeed ship new stuff and "make it stick". Since it doesn't have that power, I repeat that Dart is fragmenting.
No one is obligated to work on extending existing standards only, not try injecting new ones. Doing both without market power to make the new ones stick is going to make a mess in my view. I keep saying this, do you disagree?
I'm the last person who wants to save JS from extinction. If it were cheap enough to kill, I'd do the deed myself. It's not cheap to kill -- quite the reverse -- and the leaked memo's assertions about it being unfixable are exaggerations at best, and betray a significant conflict within Google.
(BTW I agree there's a smell of "Java-stained ideas polluting [Dart's] design.")
If TC39 had a crack at standardizing Dart or putting ideas from it into ES6, everyone would be better off -- even if Google then launched Dart anyway.
Instead, while we in TC39 were working in the open on ES6 (which is past new-proposal freeze), we knew nothing. That is not just missed opportunity, I call it poor stewardship on Google's part.
I explicitly support Brendan's arguments. Programming languages are a STANDARD to help people COMMUNICATE units of functionality. If we frequently invent new languages that just mainly give us a new "style" to do things (and of course some will do this better, and others will do that better), we get an unnecessary chaos of different codebases that will be incompatible to each other but yet do basically the same. (1)
Language design implies even more responsibility in versioning and adaptation to new programming paradigms than API design.
Let me again cite Atwood's Law: "Any application that can be written in JavaScript, will eventually be written in JavaScript." (see http://www.codinghorror.com/blog/2009/08/all-programming-is-... )
It doesn't matter that much in which language a program is written, as long as the language level fits the level of your module / application and portabiliy (1) is high.
I would even vote against a separate module type and other experiments that complicate JS sytax. But this is, of course, another discussion. What I like and heavily use is CoffeeScript.
Thank you Brandon for keeping things in order!
Without further nuance, saying "standards must keep up, deal with it" is a bit too consequentialist for me, a Mozilla founder, or for anyone working sincerely in the open web standards bodies. Korean and Chinese banks still require ActiveX PKI plugins or else deny service. The end of better web tech does not justify any means, especially not single-vendor locked-in means.
It seems to me Google is trying to have it both ways, which creates not just the appearance of a conflict, but an actual conflict: does their top talent work with standards bodies to make interoperable specs (based on prototypes and open source and so on), or do they go for wow-effect and sweet-talk if not strong-arm tactics?
Google knows they can't standardize something like NaCl. My belief is that control flow integrity enforcement will sooner come to OSes and OS-targeted toolchains than it will to browsers via NaCl and Pepper. So, safer (but still OS-specific) binary plugins, in the next five years. But mapping Pepper, an unimpressively large and messy API tied to Chrome as well as WebKit, onto other browsers? Other vendors won't get on that treadmill, and I don't believe Google would try to "do it for them". Gears was too painful.
On Dart: Google as a single entity does not know what could be done in Ecma TC39, since the Dart/V8 principals never participated, and V8 needed a fresh-thinking second team finally to get going on Harmony prototyping. But let's agree that one or two designers work better sprinting alone, not burdened by a committee (see my blog post for how we avoid design by committee).
Then Dart could come to Ecma as a proposed spec with a single open source implementation, perhaps later this year or early next. This was not part of the leaked game-plan, however. Clearly Google did not, as of that document's date, intend to standardize. And who believes they would give up "design control"?
Would TC39 entertain Dart as a second language? I doubt it. A whole second spec to write and get through ISO, cross-language-heap cycles to collect, mixed and possibly conflicting runtime semantics, specifically more numeric types in Dart than current JS to coerce and/or fail to convert in the native/managed bridges and API stubs, the list goes on.
Would TC39 take inspiration from Dart and fold ideas and design elements into the Harmony agenda? Absolutely we would, but we need to see Dart first, and this last week does not make for an auspicious launch. Still, no hard feelings if we do get a clean pitch from Dart principals to TC39.
However this plays out, Google has a lot of power. I won't quote Spider-Man's Uncle Ben, but for a company that moralizes about evil-as-in-don't-be, the standards they hold themselves to have to be high. I argue that they can't successfully and faithfully both work for interoperable and better web standards among multiple browsers, and play deep proprietary lock-in games. Pick one or the other.
Innovating in the open and proposing early and often to standards bodies are fine. Delayed-open-washing and increasing piles of proprietary (open-source doesn't matter) single-vendor code, which implements features that are not ever proposed for standardization, are not.
Even if any means are justified toward the end of improving web programmer productivity over what JS affords today, Dart represents a specific, clear and negative judgment on the Harmony work in Ecma, a judgment that I believe will be shown to be a mistake. It can't possibly help us make faster progress in TC39 -- it's at best a distraction and at worst a break in trust among the members.
With tooling (Brightly) and massive developer and evangelism resources backing Dart, will we really have the kind of open-web-first, fair-play contest that people who thought Google was (as Paul Graham put it) "aligned with the grain of the web" have come to want and expect from Google?
It looks like we won't. GOOG is acting more like MSFT of old (also like AOL, wanting sticky eyeballs and time-on-site instead of being the best search engine). The game theories of public companies, the innovator's dilemma, the Facebook challenge, and the browser-vendor Prisoner's Dilemma, all predict this ironic development. It is not a surprise.
But companies are made of people, and I have hopes that Googlers on the right side of this conflict will speak up.