I disagree with his premise.

The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where other browsers don't use the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript performing the same task in another browser.

If direct Dart code runs faster than JavaScript on Chrome, that's a nice bonus, but if it runs as well as similar code that was originally written in JavaScript on the other browsers (when the Dart code is compiled to JS) that's good enough. Dart on the other browsers isn't competing with Dart on Chrome, it is competing with JavaScript on the other browsers and that's how it should be measured.

And if it turns out apps in Dart on Chrome really blow away apps in JavaScript on other browsers to the point where both devs and users start embracing Chrome even more for these gains then hopefully that will light a fire under everyone else to either adopt Dart or do something to fix what would then be an undeniable problem of JavaScript.

I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language".

If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en masse, then suddenly a chunk of the web "works best in Google Chrome", and every other browser manufacturer is put into a very, very awkward position. They can do nothing, in which case their continued relevance depends on Google continuing to ship the Dart → JS compiler (and diminishes as users switch to Chrome). They can license the Dart VM from Google, in which case their continued relevance depends on Google continuing to license the VM and we have another large chunk of the Web based on a single binary monoculture (which worked so well for Flash!). Or, they can try to develop their own Dart VM, in which case they'll be eternally chasing the tail-lights of Google's VM, kept behind by Google's head-start and Google's engineering power. None of those options is very pleasant, in the long run, for anybody who doesn't own Google stock.

As Brendan's original comment points out, this choice is not unique to Dart. Currently browser makers have picked option 3 ("write our own") to deal with V8, option 2 ("licence Google's implementation") to deal with WebM, and so far option 1 ("ignore it") to deal with SPDY.

Under the carefully-managed tension of ECMA, the ECMAScript standard has become a much more practical language to develop in directly, and to target from higher-level languages — and with the agreement of all the major browser vendors including Google. It's not immediately obvious that a project like Dart is even needed; even if it is a major technical advance, it's a political regression.

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).

This is all documented on http://wiki.ecmascript.org/.

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.

Does it matter who said that? I don't think so.

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?

This is what this conversation is starting to sound like: http://www.youtube.com/watch?v=tOrI6uqS-vk

More than syntactic sugar is being added, for instance:

https://developer.mozilla.org/en/JavaScript_typed_arrays

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.

Modules, which are statically bound, are part of ES Harmony [1]. Please stop spreading falsehoods.

[1]: http://wiki.ecmascript.org/doku.php?id=harmony:modules

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.

Exports from Harmony modules are frozen and cannot be changed at runtime. Classes are too if you use Object.freeze().

The points you're using to substantiate your argument are not really in line with the facts. Many browsers broadly share a single implementation for huge chunks of the web. Examples off the top of my head include NSS, WebGL, LibPNG, LibJPEG, and WebM. And it's inaccurate to claim WebM is "licensed" from Google; that's no more true than claiming that NSS is "licensed" from Mozilla. Both are open source projects accepting third-party contributions. People can happily use the code as is, contribute to changing it, or simply fork it off.

Finally, you seem to have missed the fact that Mozilla is already working on an experimentatl implementation of SPDY in Firefox: http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-yo...

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason for it's success, despite its shortcomings. I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore.

Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them.

The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight?

For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval)

Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU.

Something like DVM, or a bytecode specifically designed for JS would be better I think.

There's a difference between open-source software and an open-source project. For example, compare the PostgreSQL and MySQL databases. Both are released under an open licence, but PostgreSQL is developed openly on a mailing-list and anyone can step up and contribute, while MySQL is developed privately by an organisation, with occasional source releases. No single entity has a majority control of PostgreSQL, but Oracle has a pretty firm grasp of MySQL.

Likewise, even though Dart is supplied under an open licence, it remains to be seen whether it's operated more like PostgreSQL or more like MySQL. As I understand it, the V8 project is somewhere between the two, and Android is way up the MySQL end of the spectrum. Based on what Brendan has said, I doubt Mozilla would want such a large part of their platform based on a black box they can't control, and I can't really imagine Microsoft doing it.

I don't think your Unix example is quite fair; the number of Unix systems on the planet is orders of magnitude smaller than the number of web-connected system. Even so, there's still a lot of people working with Darwin in the guise of iOS and OS X, and there's a decent number of computers running non-Unix-based operating systems too.

I'll confess I'm not too familiar with the exact changes planned for ES.next, I just recall Brendan saying that improving JS as a primary language and as a compilation target were major goals in the ECMAScript committee. Maybe it's not there yet, but it can get there faster than it will take to add performant Dart VMs to every browser.

Brendan talks about the specific issue of a standardised bytecode here: http://news.ycombinator.com/item?id=1905291 (as part of an entire thread on the topic)

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore."

Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever.

"On mobile devices, loading a lot of Javascript is expensive"

I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this?

"could be atleast partially statically optimized for a particular device platform"

I don't want this at all. That's too close to ActiveX for comfort.

"wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)"

You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.

Who said anything about Java bytecode? Java bytecode != bytecode.

"I don't want this at all. That's too close to ActiveX for comfort."

It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today.

In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices.

As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings.

The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.

"They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices."

Wrong. SpiderMonkey doesn't. It retains the bytecode only, throws away the original source, and uses a decompiler when toString() is used. V8 saves the original source, but that's its problem :)

I don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).

It has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.

"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one."

It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.

No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation.

And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too.

[1]: http://java.sun.com/docs/white/langenv/Security.doc3.html

Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.

That statement came with no benchmarks or numbers, no knowledge of the Dart VM and it's relative performance to V8, and no knowledge of the Dart to JS compiler and what kinds of optimizations it does.

If you run Google's closure compiler on JS, for example, in some cases, it produces a very significant speedup than hand-tuned hand-written JS, so saying "never be decent" is a pretty strong claim to make.

The key part is (...) compared to having the Dart VM in the browser.

It seems pretty obvious to me that unless Google fucks up the VM implementation, it'll always be much faster than compiling to JS, which doesn't even implement the same concepts - let alone semantics - of Dart. In fact, if VM is not much faster, why would they have it at all?

Being faster than handwritten JS is irrelevant, because the VM will be faster still, and that's the difference he's talking about.

Browsers already have a wide performance differential. What's the ratio between V8 and IE6? Or between desktop and mobile? As long as the performance isn't pathologically bad, it won't matter. Dart apps will start up quicker and run a percentage faster. Maybe perform much better on mobile. A decent win, but doesn't really change the fragmentation equation much from what it already is.

The keyword Brendan used was "decent", and frankly, I'll take a stab and say performance of Dart to JS will be beyond decent.

I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 for a clue.

Dart-to-JS can't be faster than hand-coded JS if it does not use bignums. If it does use bignums that do not fit in 32-bit ints, then Dart-to-JS will be slower than a native VM with built-in bignum support.

IE6 is irrelevant. The topic is modern browser with native Dart VM vs. without.

What do you mean Dart-to-JS can't be faster than hand-code JS? That's like saying C can't be faster than hand-coded assembly. Unless you write unmaintainable code or spend efforts counting cycles and scheduling and pipeline harzards, this usually isn't the case, and is not the way most people write large application (all in asm). If you take your average hand-written Javascript and run it through closure compiler, in many cases, it ends up executing faster (at least in V8). If you haven't already, I would recommend investigating the behavior of JS VMs with and without Closure Compiler, you might be surprised.

We're talking averages here, not pathological edge cases. Java has a 64-bit long type which JS doesn't support. GWT supports longs. In theory, GWT code should run slower, in practice, because GWT contains an optimizer, it runs as well, or faster, than hand written JS, simply because very few code bases have hot paths dependent on long arithmetic. For example, I've actually ported popular JS benchmarks to Java, ran them through GWT, and the result was faster.

Sure, would you be able to concoct applications for which Dart and Dart-to-JS have a large divergence? Yes. Will they be the common case? Probably not. I can concoct normal JS applications today which show high divergence between Chrome, Firefox, and IE, because of all of the JS VMs have different weaknesses, different optimizers, different garbage collectors. If you're writing applications that are so CPU bound and performance critical (e.g. games), chances are you're going to run into other portability problems too.

Most of this worry over runtime performance I think is a red herring. The real difference will probably be in startup time.

"That's like saying C can't be faster than hand-coded assembly"

Don't change the subject. The topic is not productivity as you seem to imply here. Also, JS engines are not hard to track super-scalar CPUs. A compiler can target one JS VM (e.g., V8) but then you're locked in. All the current JS VMs have peculiar optimization faults, some worse than others, many completely disjoint across VMs. No one has a compiler targeting each to best effect.

Hand-coders can do well in general against current JS trans-compilers, but that wasn't my point.

The point is that if you actually need bignums, a JS emulation will be slower than a native Dart VM built-in bignum implementation.

"Most of this worry over runtime performance I think is a red herring."

The "worry" (such as it is, or was) was over Google's politics, not its Dart-to-JS compiler's generated code performance in isolation. Pushing a native Dart VM into Chrome, rewriting major Google apps to use Dart, then seeing if that creates market pressure for native Dart support in other browsers, was all suggested or even explicitly called out in the leaked memo. That was the "worry".

But it sounds like a native Dart VM in Chrome won't be immediately released, and the Google web apps written in JS or Closure won't be rewritten quickly. I don't know. Maybe you do -- do you work for Google?

What percentage of apps do you think bignum performance will matter? Even in cases where it might matter (cryptography), you would be better suited using GPGPU code, or adding cryptographic APIs to the browser itself rather than insisting it be done in JS. Indeed, you could always fallback to that for browsers with poor bignum performance.

GWT has supported Java's BigInteger/BigDecember, and it's never been an issue.

(For the record, since it is no secret by searching my handle, I work for Google, but I do not work on Dart. I specifically work on the GWT compiler, and do not speak for the Dart team nor represent their views, nor am I really representing anything, but my own biases here given my experience with trying to develop high performance Javascript games both in the browser and mobile)

If bignum performance doesn't matter, then Dart-to-JS code is generally no faster than other JS code. Duh!

If, as the leaked memo asserted, JS's lack of more than one number type is "unfixable", and we now see that Dart's fix is to add bignum as well as double, then bignum must matter. Else why do bignums in Dart?

This ignores the live bignum strawman on the ecmascript.org wiki, which Googlers on tc39 failed to champion.

If your argument is that bignum literal and operator syntax, not bignum performance, are what matters, I am with you -- but then why did no Google rep on tc39 work to advance the bignum strawman?

You can't have it both ways. It looks like some Google heavy hitters focused only on Dart as if it has a native VM, and not on Dart as a source language for JS, which implies certain obvious extensions to the ES standard.

And in any case I seem to recall being assured by Mozilla that we don't need no Native Client because Javascript is going to be fast enough for everything. Even pre-existing non-JS code could just be compiled to mighty JavaScript, the Assembler of The Web™ and all would be well. But now Dart is unacceptable because Dart-to-JS won't be close enough to the performance of native Dart?

Go back to the other thread and re-read the argument there (or go back to school and learn how to argue). No one said Dart-to-JS by itself was bad for anything.

The leaked memo spoke of a native Dart VM in Chrome and Chrome-first Dart as primary source web app authoring by Google. The clear intent was to pressure other browsers to adopt the native VM.

Google can act like Microsoft (but with less market share) if it so chooses. Just spare us the open-washing hypocrisy, and don't expect productive multi-vendor standardization. Instead, expect a new browser cold war -- no one wins.

You appear to have misunderstood.

On one occasion Mozilla has argued that the speed difference between a) non-JS code running natively and b) the same code rewritten in, or even compiled to, JS is (or soon will be) too small to be important. Now on this occasion Mozilla is arguing that the speed difference between a) native-VM Dart and b) Dart-to-JS is (and will remain) large enough to be important. I pointed out that these two claims are hard to reconcile. About the only way they can both be mostly-true is if the performance gap only happens to be large and important enough on exactly those occasions when that gap happens to bite Mozilla in its platform strategy. Not very likely, unless one assumes that the performance needs of the poor sods who just want to use the web (as publishers or consumers) are never all that important.

So the fact that Mozilla's problems with the relatively poor performance of Dart-to-JS would be solved if native-VM Dart went away has little relevance, because most other people's problems with the speed of JS are not helped by making there be no alternative to JS.

> or go back to school and learn how to argue

http://www.youtube.com/watch?v=SKm5xQyD2vE

so let me get this right: you are arguing that a problem with Dart is that other browser makers won't get on board, and you happen to be CTO of one of those browser makers?

That seems a rather circular reason for dismissing it.

re: brand new: fine, wait until it isn't brand new

re: lock in: I'd think Mozilla isn't really locked in as long as there is a cross-compiler. If you decide the the code bloat isn't worth the speed improvement (for the sites that run dart code), yank the VM and no harm done

re: opportunity cost: well the code from Google can be dropped in, unless you really feel the need to rewrite your own version.

re: "free lunch to a competitor": it sounds like if there is is potential for another "browser war", it's coming from that sort of attitude. In fact, that sounds counter to the whole concept of open source.

re: "It doesn't matter how good Dart is.": well, that's a shame. I'd like to think merit counted for something.

Overall, maybe I don't know your world and the politics etc, but it just sounds like a lot of "not invented here" syndrome to me. And I say this as someone who genuinely admires your work and really likes Javascript (and am especially pleased that Dart looks enough like Javascript to be comfortable to me).

You seem new to software. Every addition costs. The 2nd scripting engine in particular. Mozilla went through this to no avail with CPython several years ago. I paid Mark Hammond to do the integration work. It was a constant source of bugs and overhead, and without CPython distribution on Windows, and sane versioning on Mac and Linux, no one used the non-JS code paths save ActiveState in Komodo.

WebKit is supporting Python bindings but that language is 3rd after Objective-C and Apple pays the big Obj-C costs.

My comment about Dart's merits was purely a businessman's evaluation, not NIH. Before you throw that accusation my way, consider Mozilla using Google WebM code, and lately implementing SPDY.

You expect other competing browsers to give Google a strategic free lunch, and to give up their share of influence in standards bodies? No way, not from us, or from Apple or Microsoft or Opera.

But it turns out Dart does not have obvious merit, such that I am moved to implement it (see SPDY for a counter-example). Dart is jejune, knee-jerk, and conservative in its design, from what I have now seen.

I have no doubt that there would be a cost associated with hooking in Google's code. And I'll take you at your word that it's not NIH, even though a casual reader might guess that you might be a bit more personally invested in Javascript than you'd be in the various things that, say, WebM seeks to replace.

Regardless, I'll leave your words to speak for themselves without further debating. I'll admit I'm a tad disappointed at the level of defensiveness and name calling (of both your competition and of those you debate with), though.

You had better put up or shut up. I did not call anyone names. Cite my words if you can.

As for defensiveness, that looks like your department.

Well, uh, I guess if you put it that way, I sure better....

Whether you want to debate whether the term "name calling" is accurate or not, I would suggest that the following fall astray of Hacker New's guidelines of "the principle here is not to say anything you wouldn't say face to face". Then again, I don't know.....maybe you are that way in person too.

"Grow up!"

"Such ignorance. Willful? You seem new around here, and you are not using your real name"

"How old are you, to never learn or else to forget this?"

"So your trollish commentary notwithstanding"

"I despair of your reading comprehension"

"Am I promising you a pony? No, but then you are not a three-year old."

"(or go back to school and learn how to argue)"

"Dart is jejune, knee-jerk, "

and of course:

"You had better put up or shut up"

Really? It seems you're quite a prominent figure to need to resort to that sort of schoolyard talk, but do as you wish. I'm not going to be baited anymore.

Thanks for javascript, though.

Name-calling means calling a person a name. If I say "Joe is an idiot", I have called Joe a name.

If, on the other hand, I call someone's behavior or rhetoric out, then that person has room to back up. We all make mistakes -- definitely me included.

Your previous comment accused me of NIH without evidence. I talk back to that kind of crap. I'm not baiting you. Let us take each other at our word.

For what its worth, I felt really awkward reading many of your replies in this thread. You are our spokesperson for JavaScript and the CTO of Mozilla. It would be nice if you could talk to people without making disparaging and downright condescending remarks.

I look up to you to speak for the community and to use judgement and character. Anyways, maybe I'm just being too sensitive, but I figured I'd say something.

I take your comment to heart. Sometimes I bite back too hard.

To all those here to whom I've made "grow up!" and similar remarks, my sincere apologies.

Much appreciated. =)

I don't think any browser manufacturer would have an issue with Dart if it were only a Dart-to-JS compiler. Nobody had issues with GWT or CoffeeScript, after all.

> In fact, if VM is not much faster, why would they have it at all?

Google hasn't made dart so we can make our web apps faster. They made dart because there's a lot of java developers at google who believe that its easier to write monolithic javascript applications (GMail, G+, etc) using a language like java.

They believe it enough that they will try to convince others to follow suit.

No, I was asking "why would they have [the VM] at all?"

If the VM wasn't (much) faster than the Dart-to-JS compiler, there would make no sense to have both.

What Brendan is missing is that the contest is not closed between JavaScript and Dart. The elephant in the room is the huge and growing mobile space where ObjectiveC and Java rule. It's not about "Works only in Chrome", it's about "Works only on iOS/Android".

What you are missing is the bleeding obvious: the topic of that other thread where I commented was Google's leaked memo about Dart as "replacement" for JS -- that memo created "the contest".

Obj-C and Java are not browser-supported. Sure, there's a native apps vs. web apps contest. Native is winning? Not according to Fred Wilson (AVC) and other observers.

Who knows, really. We're speculating, but let's find out by doing. Mozilla is working on both Open Web Apps that run in modern browsers, and Boot To Gecko.

With all due respect to the awesome work Mozilla is doing, I'm not seeing in your response anything about mobile-native-jshtml5 platform. Funny enough, Microsoft is currently promoting jshtml5 as a platform harder than Mozilla is, and given their platform unification message, that ought to include the mobile/tablet space as well.

Edit. I'll have to retract the above. BootToGecko is the mobile platform from Mozilla. It would be awesome to market it harder as such.

Thanks for the retraction, and you're right: we are not going head-on against "mobile-native-jshtml5" (new one on me, but I know what you mean). I'm talking about B2G at Web 2.0 Expo New York this week. We will work up our marketing as we get closer to first hardware product launch with our partners.

Edit: we are, however, trying not to make special sauce on top of the web standards. Instead we're working with W3C and WAC to standardize device APIs progressively as we go.