I understand the context and still disagree. If Dart is so much better than JavaScript on Chrome and if its Dart->JS engine does a good enough job of creating usable JS on other browsers that developers are willing to commit to using it to write apps then, well, that's too bad for everyone else, isn't it?
Why should Google put the brakes on improving client side development just because it puts other browsers in the uncomfortable position of having to license Dart (for free, since it is OSS and has a liberal patent grant)?
The same would be true if Microsoft created some sort of .NET->JS compiler with their own VM for IE, or if Mozilla did the same with some new language. As long as they bridge to JavaScript, more power to them. Client side web development could certainly use some of the tools that these different language environments could offer and if it kicks off another performance race to get browser-side languages even faster (especially on mobile devices), so much the better for everyone.
I really don't see how there is any downside (to anyone but maybe Brendan Eich) to widespread usage of Dart unless the Dart->JS code proves to be suboptimal, but in that case devs won't use it.
When I first got onto the Internet, nearly every page I came across had a little image at the bottom saying "Best Viewed in Netscape Navigator". Since I was using Netscape, everything worked fine and I didn't care. Some time later, I began to see images saying "Best viewed in Internet Explorer". Everything still worked fine, so I still didn't care... but as time went on, more of those images popped up, and the pages they appeared on began to look much, much scrappier in Netscape than they did in Explorer. While most of them still worked, more or less, Explorer made a noticeable improvement.
So, three cheers to Explorer for defeating Netscape and improving client-side development for everybody, right? Find a web-developer who still has to work with IE6 and ask them what they think.
Right now, Dart is freely-licensed and available to everybody, but who can contribute to it? Who will be allowed to veto compatibility-breaking changes? What happens if Apple announces some new hardware platform, and then Google coincidentally decides that supporting that platform in the Dart VM is no longer a priority, refuses to accept patches for it, and later refactorings happen to make it very difficult to maintain outside the official tree? What if the Dart VM becomes strategically important like Android, and current releases are only available to approved partners?
Sure, it's very unlikely that all those things would happen, and fairly unlikely that even one of them would: up until now, Google has stuck pretty close to the "do no evil" thing. But if we stick with openly, collaboratively created technologies, those things are impossible, and "impossible" is better than "unlikely" in my book.
If Dart were some kind of server-side thing Google wanted to use to increase the responsiveness of their sites, or something else internal to their systems, I wouldn't care — they're allowed to do whatever they want in the privacy of their own servers. It's only because the value proposition of Dart is "give Google an inherent advantage of control over the Web, and in exchange you will get shiny things" that I'm concerned. There'll always be more shiny things, but (so far) there's only one Web.
"So, three cheers to Explorer for defeating Netscape and improving client-side development for everybody, right"
Abso-friggin-lutely! You should be thanking Microsoft and Internet Explorer for upping everyone's game. They're the ones who introduced XmlHttpRequest. You knoww, "ajax"?
It's their browser and they can do what they want with it. If you don't like it, don't use it. If everyone else likes it though, tough luck for you. Go build your own browser and language and drum up your own support for it. All of this political correctness is a bunch of bull.
Must some historical fact or pattern of facts be "all good" or "all bad"? Grow up!
Microsoft added XHR to IE when they gave Java the boot in a spat with Sun, in order to keep Outlook Web Express in working order in IE. Was that "all good"? Clearly not for Sun or Java!
The browser wars phase I had no winners. Yes, IE's DHTML innovations such as innerHTML were a win, and Netscape should have agreed to implement and standardize them. No, the long IE6 stagnation and legacy were Not Good.
Wow, really? Grow up? Nobody said it was all good for everyone. I made a counter-point that was clearly as balanced as the original point.
Anyway, it really depends on your point of view. Personally I love the IE6 stagnation and other failures that affect the web such as the epic lameness of Javascript. Why? I think the whole platform sucks and I'm glad to see it fail and push people to build better solutions.
"Abso-friggen-lutely" on top of "three cheers" lacks qualification about the thing you cheered being less than good for anyone. You were abso-friggen-lutist.
Anyway, the open web standards are not failing. Dart is not a clearly better solution. I get your point about XHR, but do try to take mine about the whole history being a mixed bag, including what IE did. We can do better.
georgemcbay basically said [why shouldn't Google do what they want with their browser?], to which thristian replies [because...Microsoft]. I think that's a bullshit argument, especially since there's nothing about Dart that threatens to take away anyone's freedom to continue using Javascript or whatever else comes along.
I gave a bullshit reply to make a point; let's call it hyperbole. Of course I know that it was a mixed bag for everyone. Some good things did come out of it though, IE6 is almost gone and those good things are still here (and they've evolved). Evolution is slow and life itself IS indeed a mixed bag. Business is WAR!!
Anyway, I love, love, LOVE the fact that people are working on giving us lowly blub programmers a choice. :)
EDIT: Didn't realize who I was talking to, so let me be really clear that I have a LOVE/HATE relationship with all things in tech, including Javascript!
I have mixed feelings about JS and most software, but moreso JS than, e.g., Unix (BSD kernel code in the late '80s, not to date myself too much).
People seem to think I have some big ego investment in JS, but it's this thing I did in a hurry, but with a purpose that caught on when the web was young and growing fast. JS is not done, yet it will be hard to replace.
JS is easier to extend than some here claim (and as my recent comments have noted, not all the parties on the record asserting that it's hard to "fix" are truly giving it their best effort). As with most web standards, you can't remove stuff predictably, but new and more winning extensions can help retire worse old forms.
Business may be WAR but the modern browser era is marked by claims of peace and openness and standards conformance. So while Dart, and (I joke; I hope this doesn't happen) matching novelties from Apple ("Flechette") and Microsoft ("Javelin"), will take some attention off the standards, the forces operating in favor of standards will probably manage to keep JS evolving.
I actually miss some of the Googlers who have worked in TC39, or around the edges, but who are now full time on Dart or other projects. It seems like a lost opportunity to me, but it's Google's call.
The alternative to google developing Dart isn't doing nothing, but throwing more resources behind javascript.
I think you are missing some of the context of Eich's comments. The very same leaked memo declared that Dart was developed b/c js could not be evolved into a suitable language. Obviously Eich thinks it can, but more to the point he's working on the committee that is responsible for guiding such evolution -- the same committee that google plays a major role in.
So the particular claim he's laying out is this: Google throwing resources behind Dart is worse for the web than Google truly committing to an evolved javascript.
You might agree or disagree with this claim, but your arguments so far have been tangential to it.
If JS can be evolved, why has it taken over a decade, and still nothing much of substance? I think Javascript is much like Java, it is too hampered by concerns of remaining compatible with existing legacy semantics. Whenever you see a language where the only thing they can add is "syntactic sugar" it means they are unwilling to consider functionality that would break the underlying legacy VM assumptions, and that means, ultimately, their evolution is "boxed in" by these concerns.
Java basically is at a dead end because changing the JVM is hard.
Such ignorance. Willful? You seem new around here, and you are not using your real name. If only we were on Google+ :-/.
The long stagnation from ES3 (1999) to ES5 (2009) had everything to do with Microsoft abusing its browser-tying OS monopoly to stagnate the web by disbanding the IE team after IE6. This was prosecuted in U.S. v. Microsoft. How old are you, to never learn or else to forget this?
When I brought Mozilla back to Ecma in 2004 as we were launching Firefox 1.0, the JS standards group within TC39 was fooling around with E4X. Only one MSFT and one ex-BEA (ex-MSFT before that by way of Crossgain) guy were doing the spec work, and IE was not ever going to implement E4X.
We had to restart browser competition to get the various parties (Apple and Opera too) back in the room and working productively on the core language.
Now, we have ES5 done and ES6 under way. ES5 had new semantics, ES6 has more along with syntax, chiefly the module system (a second class system to facilitate prefetching, along with a loader API for when you need to be dynamic).
So your trollish commentary notwithstanding, ES5 is done and shipping in the latest browsers (finally complete in IE10 previews), and ES6 is being drafted and pieces are being prototyped in SpiderMonkey and V8.
I'm the last person to defend Java, but the JVM deserves a word here: it has finally evolved a bit, and it is fairly thriving on the server side with Scala, Clojure, and other languages.
Java's stagnation was due to Sun's miscalculations and mismanagement over the years.
You accuse me of trollish behavior, yet resort to personal slights, asking how old I am? Irony. Did I ever question your age or intent? I am fully aware of Microsoft's behavior, but that still doesn't address the fundamental issue that language evolution within spec committees is painfully slow and the competing interests waterdown proposals. It happened to C++ and to Java too. It happens in our government as well, we often don't get what's best or right, only what you've got the votes for.
The issue is whether or not any large changes can be pushed through in a timely manner, if the need arises. I've seen, over several threads, you seem to simultaneously stress the idea that Javascript performance is good enough (vs native), a Dart VM performing better than JS is a problem, and that whatever performance problems there are, they'll be resolved by better JS VMs. Not only are those hard to reconcile, but it requires a great leap of faith to believe that they will, because we've heard it all before. We've heard the same arguments about Smalltalk performance, about Self performance, and of course, the JVM, that the performance differentials will be tackled.
As for the language ecosystem on the server, yes, it's wonderful, but happened in spite of the JVM, not because of any evolution in it. The fact remains, Java changes were often evaluated towards remaining binary compatible with existing bytecode (e.g. erasure vs reification) and that caused the vote down of language proposals. (the same problem did not occur in C#/CLR)
My question is, when can I write a mobile web app using Javascript, that performs as delightful, in startup time, in runtime performance, in lack of janky-ness, for a mobile device, that doesn't burn battery or memory? Are you promising that evolved JS is going to fix this issue?
We agree on Java the language being mismanaged. Especially in comparison to C# (see a recent InfoQ interview with Neil Gafter). But the JVM is in better shape.
I despair of your reading comprehension, though, when it comes to what I have written about the leaked memo's Dash strategy. I never wrote that JS can be as fast at Dart-to-JS code as a native Dart VM could be. Not ever -- quite the reverse.
Now if we on TC39 had the benefit of Google's Dart expert input any time in the last year, we could have possibly worked harder on guards (optional type annotations), branding (aka trademarking, nominal types for use with guards), bignums, classes, or other proposals that have suffered in comparison to those that clearly made it into ES6. FYI, these were all strawman-status on http://wiki.ecmascript.org over the last year or so.
Some Googlers on TC39 did work on a few of these, in most cases too late for our agreed-upon ES6 proposal cut-off date. We did hear a dire warning from one Google rep in May 2010 that if two of these proposals were not promoted to Harmony status, JS "would be replaced!"
So your complaints about the ECMA standard not progressing fast enough come with ill grace from a google employee. Google has a lot of power and it has not discharged it responsibly, in my view. ES6 would be a better Dart-to-JS target language, including draft specs and prototypes in V8, if it had made a concerted effort.
Contrast this with Mark Miller (Google) and Tom Van Cutsem working in the open, and very effectively, on ES6 proxies, already prototyped in SpiderMonkey and V8. Or the module system designed by Dave Herman and Sam Tobin-Hochstadt in the open, which you overlooked.
Talk about self-fulfilling prophecy! In this case, you are not even predicting the future, you're misstating the past.
I think if it wants to be taken seriously as a good force in advancement of the web, google does have to be aboveboard with its involvement in TC39 and put in significant effort there. Maybe they really should have put in more effort to pushing strawmen through (I wasn't paying enough attention a year ago to comment on that).
But are you suggesting that particular people at google should have been (forced to be?) more involved in TC39 efforts? I don't think you can force that (and someone like Lars Bak would probably just leave if he didn't want to do it). There are lots of language experts out there that are working on their pet compiler instead of helping with the next coffeescript variant. That's not an evil, it's just a missed opportunity (and the reality of trying to get good people involved with a standards process).
I think that your better argument is that an open Dart repository from the start could have fed ideas back into TC39 process, but the problems you mention didn't suffer from lack of knowledge about them, just champions for strawman solutions. That is, again, not a job that most relish.
> We did hear a dire warning from one Google rep in May 2010 that if two of these proposals were not promoted to Harmony status, JS "would be replaced!"
"Unnamed sources at Google suggest gmail actually runs on the blood of orphans, kittens." What are you, a Techcrunch guest columnist? Give a name or don't bring it up.
You seem scandalized by the idea that an employer might force employees to work on standards (or anything else per typical work-for-hire contracts).
That is not unusual. It's dog-bites-man.
What's going on is unusual, in my experience.
Google is forcing people it employs off of tc39 work. I will not say whom, since I was told in confidence. Three people at least. This casts a different light on the Dash memo's serve-two-masters glibness, and on Alex Russell's recent blog post.
Am I promising you a pony? No, but then you are not a three-year old. I am simply working every day to advance the open web, including JS, including on mobile devices. What are you doing, besides asserting falsehoods about the JS standard and its leading implementations?
I'm super familiar with type arrays (I helped port GwtQuake which was one of the first apps to ever use them in large measure), but type arrays are an add-on API that doesn't change language semantics. Something that would change language semantics would be to offer early-bound namespaces. Early-binding would increase performance while simplifying VM implementation and make tooling easier.
Sorry, I'm out of date, when ES4 was terminated, John Resig said this: "Some ECMAScript 4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony."
Is static scoping the same as early binding? For example, it is guaranteed that any class layouts within the module are statically frozen and cannot be altered at runtime? If you can add or remove methods from a class within a module, it's not really early binding, and this inhibits it's usefulness in a refactor or an IDE trying to do accurate usage search or code assist.
Why should Google put the brakes on improving client side development just because it puts other browsers in the uncomfortable position of having to license Dart (for free, since it is OSS and has a liberal patent grant)?
The same would be true if Microsoft created some sort of .NET->JS compiler with their own VM for IE, or if Mozilla did the same with some new language. As long as they bridge to JavaScript, more power to them. Client side web development could certainly use some of the tools that these different language environments could offer and if it kicks off another performance race to get browser-side languages even faster (especially on mobile devices), so much the better for everyone.
I really don't see how there is any downside (to anyone but maybe Brendan Eich) to widespread usage of Dart unless the Dart->JS code proves to be suboptimal, but in that case devs won't use it.