5 ms·

It's safe to defend Dart to the point that your Gmail will run faster in Chrome that has Dart VM. Then Firefox and IE might fall behind in performing for Google

by msoad 13y ago

It's safe to defend Dart to the point that your Gmail will run faster in Chrome that has Dart VM. Then Firefox and IE might fall behind in performing for Google web apps and then you will see how Dart will hurt web ecosystem. I'm just guessing. So far Dart2JS is pretty close to native Dart.

haberman 13y ago
To me this is like saying: "it's safe to defend Servo up to the point that it's faster single-threaded browser engines. Then Chrome and IE might fall behind in performing for web apps and then you will see how Servo will hurt the web ecosystem." To be honest, I hope that Servo out-performs the current browser engines, and the that other browsers feel pressure to follow suit, because it will push the web forward as a whole. It's like SpiderMonkey and V8 did with JS performance five years ago. Now you will probably say "but Dart is a new content type," and I see where you are coming from. But to me it's no different than asm.js. asm.js a new content type also, it just happens to be very clever and outputs programs which are a Polyglot (http://en.wikipedia.org/wiki/Polyglot_(computing) http://en.wikipedia.org/wiki/Polyglot_(computing)) of the new asm.js content type and regular JS. It is very cool how they have done this, but it doesn't change the fact that asm.js, when processed by an asm.js-aware compiler, is a different content type than regular JS and is processed in a different way that is intended to be faster than plain JS. So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward.
- Touche 13y ago
  No one has a problem with Dart2JS. We welcome more language choice on the web. People have a problem with Dartium because it's an attempt by one company to bully the rest of the web into adopting their own proprietary technology.
  - haberman 13y ago
    It's no different than putting an asm.js processor into a JS engine. asm.js is equally "proprietary" (actually more so, it's not on any standards track), and if it's truly faster than plain JS, then it's equally "bullying." (Note: I actually like asm.js a lot and don't think that healthy competition is "bullying").
    - Touche 13y ago
      Are you being serious? asm.js is basically a "best practices" guide for js vm authors. It's not required to run asm.js code, or even guaranteed to be faster; other js engines have optimized for asm.js code without treating "use asm" special. Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers.
      - haberman 13y ago
        > asm.js is basically a "best practices" guide for js vm authors. No. It is a specifically designed subset of JS that also has extra annotations. If a block of code does not adhere to the rules, it is not asm.js and will be processed as regular JS. If it validates, it is processed by a different compiler pipeline and AOT compiled. It is much more accurate to say that asm.js is a newly designed byte-code that very cleverly happens to use backward-compatible JS as its serialization. Native Dart is also not guaranteed to be faster than Dart2JS. > Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers. Ah but that is only extra work for the developer. Similar to compile-to-JS languages like TypeScript, CoffeeScript, Emscripten, etc. there is no problem with new technologies that impose extra work on the developer, because it is the developer's choice to use it or not, so the person making the decision is the one paying the extra administrative cost.
        Touche 13y ago
        It's extra work that a lot of developers aren't going to do. "Works in Chrome, closes ticket". Can't even get developers to use css prefixes properly. Hence why I called Dartium bullying. It's an attempt to reinvent the web with Google in control. asm.js is just an attempt to make existing vm optimizations a little bit better (and again, others disagree that they are needed).
- pcwalton 13y ago
  > To me this is like saying: "it's safe to defend Servo up to the point that it's faster single-threaded browser engines. Then Chrome and IE might fall behind in performing for web apps and then you will see how Servo will hurt the web ecosystem." We are not implementing anything in Servo that does not have cross-vendor support and is on standards track. That's not the same as Dart.
  - haberman 13y ago
    I address this argument in the rest of my comment. Asm.js is not standards track as far as I know. Actually let me post a thought experiment. Suppose that Dartium, instead of processing straight Dart source, processed a format that is like JS except that all the Dart is in JavaScript comments at the top of each Dart2JS-outputted function. And suppose developers compiled their Dart to these JS-with-Dart-in-comments files, and distributed these on the web instead of Dart and JS as two separate files? At that point, how is Dart different than asm.js?
    - pcwalton 13y ago
      > At that point, how is Dart different than asm.js? It's not guaranteed that the Dart VM and the dart2js-compiled code implement the same semantics. (And, in fact, they don't, by design—bignums operate differently in JS and the Dart VM, which could break sites in non-Chrome browsers.)
- azakai 13y ago
  > So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward. I think this is potentially interesting comparison. Yes, both Dart and asm.js are tools that are involved with both generating content and executing that content (unlike your first example with servo, which is apples-to-oranges for the reason you mentioned). But there are big differences here. With asm.js, it was a specific goal to make optimizing the code in other browsers as simple as possible. That was one of the main reasons for actually defining asm.js, so there is a clear "contract" - "this is what compiled C++ code looks like, these patterns are easy to optimize in obvious ways." That avoids the risk of there being anything special about generating code using emscripten and executing it in Firefox: the generated code is asm.js with the "contract" just mentioned. For Dart there isn't anything comparable. dart2js emits JavaScript code, which runs in all browsers, but there is no reason to think it's performance is or will stay similar to the Dart VM. Instead, the Dart strategy there seems to be more along the lines of "the Dart VM is open source, if you want comparable performance to Chrome you can adopt that codebase." There is merit to that approach - it's much better than if Dart were closed source - but it is quite different than the one in the previous paragraph. The second major difference is that while both Dart and asm.js relate to both content creation and execution, one is made by Google, which owns several of the most important sites on the web, whereas the other is made by Mozilla which obviously is nowhere near anything of the sort and not even trying to be. Why this last point matters is that if the VM eventually becomes much faster than the dart2js path, Google can essentially force other browsers' hands by adopting Dart on Google sites. Imagine if google.com, gmail, google docs etc. all run much faster on the VM than otherwise - other browsers would be forced to adopt the VM to stay relevant. This is huge leverage that Google has. You can't be a browser that people use if you are not competitive on Google-owned properties. Going back to the previous point, should that happen, adopting the VM might be the only option - there is no way, unlike with asm.js, to get similar performance otherwise (in the asm.js case, the high performance is achieved with a small modification to an existing JS engine, which could be done on other engines as well - no one needs to adopt SpiderMonkey). So this is the potential bad scenario that could happen due to both of these issues. Obviously there are similarities between Dart and asm.js too, as you mentioned. But I believe the two factors I described explain much of the concern some people have about what Google's plans with Dart are. It might all end up ok, but Google might also leverage its huge influence in multiple areas for what is best for Google, and not for the web as a whole. There is no such risk with asm.js.

by msoad 13y ago

haberman 13y ago

To me this is like saying: "it's safe to defend Servo up to the point that it's faster single-threaded browser engines. Then Chrome and IE might fall behind in performing for web apps and then you will see how Servo will hurt the web ecosystem." To be honest, I hope that Servo out-performs the current browser engines, and the that other browsers feel pressure to follow suit, because it will push the web forward as a whole. It's like SpiderMonkey and V8 did with JS performance five years ago. Now you will probably say "but Dart is a new content type," and I see where you are coming from. But to me it's no different than asm.js. asm.js a new content type also, it just happens to be very clever and outputs programs which are a Polyglot (http://en.wikipedia.org/wiki/Polyglot_(computing) http://en.wikipedia.org/wiki/Polyglot_(computing)) of the new asm.js content type and regular JS. It is very cool how they have done this, but it doesn't change the fact that asm.js, when processed by an asm.js-aware compiler, is a different content type than regular JS and is processed in a different way that is intended to be faster than plain JS. So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward.

Touche 13y ago
No one has a problem with Dart2JS. We welcome more language choice on the web. People have a problem with Dartium because it's an attempt by one company to bully the rest of the web into adopting their own proprietary technology.
- haberman 13y ago
  It's no different than putting an asm.js processor into a JS engine. asm.js is equally "proprietary" (actually more so, it's not on any standards track), and if it's truly faster than plain JS, then it's equally "bullying." (Note: I actually like asm.js a lot and don't think that healthy competition is "bullying").
  - Touche 13y ago
    Are you being serious? asm.js is basically a "best practices" guide for js vm authors. It's not required to run asm.js code, or even guaranteed to be faster; other js engines have optimized for asm.js code without treating "use asm" special. Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers.
    - haberman 13y ago
      > asm.js is basically a "best practices" guide for js vm authors. No. It is a specifically designed subset of JS that also has extra annotations. If a block of code does not adhere to the rules, it is not asm.js and will be processed as regular JS. If it validates, it is processed by a different compiler pipeline and AOT compiled. It is much more accurate to say that asm.js is a newly designed byte-code that very cleverly happens to use backward-compatible JS as its serialization. Native Dart is also not guaranteed to be faster than Dart2JS. > Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers. Ah but that is only extra work for the developer. Similar to compile-to-JS languages like TypeScript, CoffeeScript, Emscripten, etc. there is no problem with new technologies that impose extra work on the developer, because it is the developer's choice to use it or not, so the person making the decision is the one paying the extra administrative cost.
      - Touche 13y ago
        It's extra work that a lot of developers aren't going to do. "Works in Chrome, closes ticket". Can't even get developers to use css prefixes properly. Hence why I called Dartium bullying. It's an attempt to reinvent the web with Google in control. asm.js is just an attempt to make existing vm optimizations a little bit better (and again, others disagree that they are needed).
pcwalton 13y ago
> To me this is like saying: "it's safe to defend Servo up to the point that it's faster single-threaded browser engines. Then Chrome and IE might fall behind in performing for web apps and then you will see how Servo will hurt the web ecosystem." We are not implementing anything in Servo that does not have cross-vendor support and is on standards track. That's not the same as Dart.
- haberman 13y ago
  I address this argument in the rest of my comment. Asm.js is not standards track as far as I know. Actually let me post a thought experiment. Suppose that Dartium, instead of processing straight Dart source, processed a format that is like JS except that all the Dart is in JavaScript comments at the top of each Dart2JS-outputted function. And suppose developers compiled their Dart to these JS-with-Dart-in-comments files, and distributed these on the web instead of Dart and JS as two separate files? At that point, how is Dart different than asm.js?
  - pcwalton 13y ago
    > At that point, how is Dart different than asm.js? It's not guaranteed that the Dart VM and the dart2js-compiled code implement the same semantics. (And, in fact, they don't, by design—bignums operate differently in JS and the Dart VM, which could break sites in non-Chrome browsers.)
azakai 13y ago
> So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward. I think this is potentially interesting comparison. Yes, both Dart and asm.js are tools that are involved with both generating content and executing that content (unlike your first example with servo, which is apples-to-oranges for the reason you mentioned). But there are big differences here. With asm.js, it was a specific goal to make optimizing the code in other browsers as simple as possible. That was one of the main reasons for actually defining asm.js, so there is a clear "contract" - "this is what compiled C++ code looks like, these patterns are easy to optimize in obvious ways." That avoids the risk of there being anything special about generating code using emscripten and executing it in Firefox: the generated code is asm.js with the "contract" just mentioned. For Dart there isn't anything comparable. dart2js emits JavaScript code, which runs in all browsers, but there is no reason to think it's performance is or will stay similar to the Dart VM. Instead, the Dart strategy there seems to be more along the lines of "the Dart VM is open source, if you want comparable performance to Chrome you can adopt that codebase." There is merit to that approach - it's much better than if Dart were closed source - but it is quite different than the one in the previous paragraph. The second major difference is that while both Dart and asm.js relate to both content creation and execution, one is made by Google, which owns several of the most important sites on the web, whereas the other is made by Mozilla which obviously is nowhere near anything of the sort and not even trying to be. Why this last point matters is that if the VM eventually becomes much faster than the dart2js path, Google can essentially force other browsers' hands by adopting Dart on Google sites. Imagine if google.com, gmail, google docs etc. all run much faster on the VM than otherwise - other browsers would be forced to adopt the VM to stay relevant. This is huge leverage that Google has. You can't be a browser that people use if you are not competitive on Google-owned properties. Going back to the previous point, should that happen, adopting the VM might be the only option - there is no way, unlike with asm.js, to get similar performance otherwise (in the asm.js case, the high performance is achieved with a small modification to an existing JS engine, which could be done on other engines as well - no one needs to adopt SpiderMonkey). So this is the potential bad scenario that could happen due to both of these issues. Obviously there are similarities between Dart and asm.js too, as you mentioned. But I believe the two factors I described explain much of the concern some people have about what Google's plans with Dart are. It might all end up ok, but Google might also leverage its huge influence in multiple areas for what is best for Google, and not for the web as a whole. There is no such risk with asm.js.