3 ms·

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

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.

icebraining 15y ago
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.
- cromwellian 15y ago
  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.
  - BrendanEich 15y ago
    I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 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.
    - cromwellian 15y ago
      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.
      - BrendanEich 15y ago
        "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?
  - leoc 15y ago
    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?
    - ootachi 15y ago
      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.
    - BrendanEich 15y ago
      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.
      - leoc 15y ago
        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 http://www.youtube.com/watch?v=SKm5xQyD2vE
- josephg 15y ago
  > 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.
  - icebraining 15y ago
    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.

icebraining 15y ago

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.

cromwellian 15y ago
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.
- BrendanEich 15y ago
  I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 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.
  - cromwellian 15y ago
    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.
    - BrendanEich 15y ago
      "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?
- leoc 15y ago
  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?
  - ootachi 15y ago
    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.
  - BrendanEich 15y ago
    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.
    - leoc 15y ago
      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 http://www.youtube.com/watch?v=SKm5xQyD2vE
josephg 15y ago
> 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.
- icebraining 15y ago
  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.