4 ms·

What are pros and cons of Dart support for Mozilla/Firefox?

by dgregd 15y ago

scriptproof 15y ago
Cons: Not needed because all the stuff will be included in a next iteration of JavaScript. This does not leave room for any "pro".
- Me1000 15y ago
  Two points: 1. We've been saying "the next version of javascript will result in world peace" for years now... 2. Dart does more than Harmony. A simple example is integers of arbitrary size.
kibwen 15y ago
Dart can optionally compile to Javascript, so a program written in Dart will run in all browsers, albeit with a fair bit of overhead from the translation (exactly how much overhead remains to be seen, but Dart code compiled to Javascript will certainly be suboptimal, or else Google wouldn't bother implementing a virtual machine solely for Dart). As far as native support in other browsers, it appears that Mozilla currently outright refuses to consider it on the principle that Dart is not developed openly and is not standardized, meaning that implementations in other browsers would have to reverse-engineer the Chrome implementation and would be at the mercy of Google with regard to compatibility. Unlike Mozilla, Apple and Microsoft appear to have rejected it out of pragmatism rather than principle. Specifically, Apple's Webkit engineers appear to object to the complexity and overhead a new virtual machine would add[1], and Microsoft has publicly stated that Dart doesn't solve any problems that can't be fixed in future iterations of Javascript[2]. For a more detailed technical and political perspective of why Mozilla won't implement Dart natively, see Brandon Eich's comments on the original Dart announcement[3] (it's actually quite an interesting read). [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... [2] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmascript.aspx http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas... [3] https://news.ycombinator.com/item?id=2982497 https://news.ycombinator.com/item?id=2982497
- spankalee 15y ago
  Dart can optionally compile to Javascript, so a program written in Dart will run in all browsers, albeit with a fair bit of overhead from the translation (exactly how much overhead remains to be seen, but Dart code compiled to Javascript will certainly be suboptimal, or else Google wouldn't bother implementing a virtual machine solely for Dart). The overhead of Dart compiled to Javascript will hopefully be very minimal, and in some cases Dart might generated code that runs faster than what a programmer might write. The reason for the existence Dart VM is not because Dart->JS will be slow, it's because Dart should be able to be faster than Javascript because it's easier to optimise. The creators of V8 are writing the Dart VM, so presumably they have some ideas about how to make it faster than Javascript.
  - kibwen 15y ago
    Good points. To clarify, by "suboptimal" I meant that the Javascript code generated by transpiling a Dart application will almost certainly be less optimal than writing that application in Javascript from the outset. But, again, whether this will be an issue remains to be seen. If there does turn out to be significant overhead to the transpilation phase, I'm curious if a pragmatic subset of Dart will emerge that avoids any language features that incur expensive tranformation costs, sort of like how some modern Python projects (e.g. Django) handle 2to3 compatibility by avoiding language features that are incompatible across versions to achieve a more unified codebase[1]. [1] http://groups.google.com/group/django-developers/browse_thread/thread/abede3685ad0302 http://groups.google.com/group/django-developers/browse_thre...
    - spankalee 15y ago
      To clarify, by "suboptimal" I meant that the Javascript code generated by transpiling a Dart application will almost certainly be less optimal than writing that application in Javascript from the outset. My point is that this is not really true. The Dart language itself is designed to compile to efficient Javascript. This is one reason it's a better solution than GWT in my opinion, because Java does not always compile to efficient Javascript and you do have to skip features like longs, Java regexes, even the java.util collections classes are heavyweight. Dart being designed from the start to compile to Javascript avoids most of these problems. Like CoffeeScript, I expect Dart performance to be very close to Javascript when compiled, sometimes even faster than what a programmer would normally write.

What are pros and cons of Dart support for Mozilla/Firefox?

by dgregd 15y ago

What are pros and cons of Dart support for Mozilla/Firefox?

Cons: Not needed because all the stuff will be included in a next iteration of JavaScript. This does not leave room for any "pro".

Me1000 15y ago
Two points: 1. We've been saying "the next version of javascript will result in world peace" for years now... 2. Dart does more than Harmony. A simple example is integers of arbitrary size.

kibwen 15y ago

Dart can optionally compile to Javascript, so a program written in Dart will run in all browsers, albeit with a fair bit of overhead from the translation (exactly how much overhead remains to be seen, but Dart code compiled to Javascript will certainly be suboptimal, or else Google wouldn't bother implementing a virtual machine solely for Dart). As far as native support in other browsers, it appears that Mozilla currently outright refuses to consider it on the principle that Dart is not developed openly and is not standardized, meaning that implementations in other browsers would have to reverse-engineer the Chrome implementation and would be at the mercy of Google with regard to compatibility. Unlike Mozilla, Apple and Microsoft appear to have rejected it out of pragmatism rather than principle. Specifically, Apple's Webkit engineers appear to object to the complexity and overhead a new virtual machine would add[1], and Microsoft has publicly stated that Dart doesn't solve any problems that can't be fixed in future iterations of Javascript[2]. For a more detailed technical and political perspective of why Mozilla won't implement Dart natively, see Brandon Eich's comments on the original Dart announcement[3] (it's actually quite an interesting read). [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... [2] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmascript.aspx http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas... [3] https://news.ycombinator.com/item?id=2982497 https://news.ycombinator.com/item?id=2982497

spankalee 15y ago
Dart can optionally compile to Javascript, so a program written in Dart will run in all browsers, albeit with a fair bit of overhead from the translation (exactly how much overhead remains to be seen, but Dart code compiled to Javascript will certainly be suboptimal, or else Google wouldn't bother implementing a virtual machine solely for Dart). The overhead of Dart compiled to Javascript will hopefully be very minimal, and in some cases Dart might generated code that runs faster than what a programmer might write. The reason for the existence Dart VM is not because Dart->JS will be slow, it's because Dart should be able to be faster than Javascript because it's easier to optimise. The creators of V8 are writing the Dart VM, so presumably they have some ideas about how to make it faster than Javascript.
- kibwen 15y ago
  Good points. To clarify, by "suboptimal" I meant that the Javascript code generated by transpiling a Dart application will almost certainly be less optimal than writing that application in Javascript from the outset. But, again, whether this will be an issue remains to be seen. If there does turn out to be significant overhead to the transpilation phase, I'm curious if a pragmatic subset of Dart will emerge that avoids any language features that incur expensive tranformation costs, sort of like how some modern Python projects (e.g. Django) handle 2to3 compatibility by avoiding language features that are incompatible across versions to achieve a more unified codebase[1]. [1] http://groups.google.com/group/django-developers/browse_thread/thread/abede3685ad0302 http://groups.google.com/group/django-developers/browse_thre...
  - spankalee 15y ago
    To clarify, by "suboptimal" I meant that the Javascript code generated by transpiling a Dart application will almost certainly be less optimal than writing that application in Javascript from the outset. My point is that this is not really true. The Dart language itself is designed to compile to efficient Javascript. This is one reason it's a better solution than GWT in my opinion, because Java does not always compile to efficient Javascript and you do have to skip features like longs, Java regexes, even the java.util collections classes are heavyweight. Dart being designed from the start to compile to Javascript avoids most of these problems. Like CoffeeScript, I expect Dart performance to be very close to Javascript when compiled, sometimes even faster than what a programmer would normally write.