8 ms·

AFAIK, Dart can run on bare JS without any extra support.

by eonil 13y ago

gizmo 13y ago
Javascript is Turing complete so of course you can compile anything down to JS. But for performance and convenient debugging native support would be a big help.
kevingadd 13y ago
Dart2js does not currently implement the whole language. Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing. I should point out that emscripten and many other JS-targeting compilers (like JSIL) emulate int64 semantics directly so that apps using them do work. It's kind of strange for the Dart team to have not gotten this right yet when Dart is at 1.0.
- WoodenChair 13y ago
  Is this is in the issues tracker at dartlang.org?
  - guipsp 13y ago
    Yes
  - azakai 13y ago
    Yes, http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533
- pcwalton 13y ago
  > Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing. That's going to be really unfortunate if pages start relying on the proper behavior and become Chrome-only as a result...
  - kevingadd 13y ago
    The comments on it in the dartlang issue tracker indicate that it has already been a problem; one commenter indicates that his contribution to a crypto library was rejected because he had only tested it against Dart and it didn't work correctly in Dart2js (due to 64-bit ints)
  - floitsch 13y ago
    That's not really the problem. Web developers have learned from the past and don't just build web-pages for one browser only. On the contrary... Developers now sometimes need to support outdated browsers with little market share (IE8 for example), instead of actively pushing the users to upgrade. The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle). After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.
    - pcwalton 13y ago
      > Web developers have learned from the past and don't just build web-pages for one browser only. This is not true in practice. Just a few days ago I couldn't use clippercard.com on Firefox for Android because the WebKit prefixes broke the design so badly as to be unusable. :( For numerous other examples: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=evangelism https://bugzilla.mozilla.org/buglist.cgi?quicksearch=evangel... > When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle). And if they don't, their pages lock their users into Chrome…
    - BrendanEich 13y ago
      Web developers know too well the trap of testing only on one browser, which when Dart comes to Chrome, will be Chrome. Testing all input data in a space that exceeds the integral domain of double is hard. Murphy says there will be bugs in other browsers when one's app tests "work in Chrome". For a wannabe-cross-browser, wannabe-standard (Ecma has a sorry history of proprietary standards: C#, OOXML) language pushed by a super-rich big company with what? 60 or more engineers on the project, optics must matter. Why not fix the bignum-not-emulated-in-JS bug? It's easy, GWT has BigInteger emulation code in JS lying around the Googleplex. Just plug that in if the code needs it. The obvious risk remains what I cited in HN two years ago: Google letting dart2js be sub-standard, using all its strength and leverage to promote Dart in combination with DartVM, letting users of other browsers "blame their browser" when things don't quite work as well as in Chrome. Given market share among browsers currently, I think this will backfire, but it could inflict collateral damage too -- on developers as well as on users. And it just plain looks bad. People expect better of Google, and they ought to. /be
- afsina 13y ago
  Please do not spread FUD. From what I see there are some extreme corner cases in Dart->Js behavior and they are well known. Dart team promises to support modern Browsers, period.
- ahoge 13y ago
  > Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?) Integers work fine up to 2^53 (9 quadrillion and some). There is also a "throw_on_javascript_int_overflow" flag, which you can use during development.

AFAIK, Dart can run on bare JS without any extra support.

by eonil 13y ago

AFAIK, Dart can run on bare JS without any extra support.

gizmo 13y ago

Javascript is Turing complete so of course you can compile anything down to JS. But for performance and convenient debugging native support would be a big help.

kevingadd 13y ago

Dart2js does not currently implement the whole language. Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing. I should point out that emscripten and many other JS-targeting compilers (like JSIL) emulate int64 semantics directly so that apps using them do work. It's kind of strange for the Dart team to have not gotten this right yet when Dart is at 1.0.

WoodenChair 13y ago
Is this is in the issues tracker at dartlang.org?
- guipsp 13y ago
  Yes
- azakai 13y ago
  Yes, http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533
pcwalton 13y ago
> Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing. That's going to be really unfortunate if pages start relying on the proper behavior and become Chrome-only as a result...
- kevingadd 13y ago
  The comments on it in the dartlang issue tracker indicate that it has already been a problem; one commenter indicates that his contribution to a crypto library was rejected because he had only tested it against Dart and it didn't work correctly in Dart2js (due to 64-bit ints)
- floitsch 13y ago
  That's not really the problem. Web developers have learned from the past and don't just build web-pages for one browser only. On the contrary... Developers now sometimes need to support outdated browsers with little market share (IE8 for example), instead of actively pushing the users to upgrade. The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle). After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.
  - pcwalton 13y ago
    > Web developers have learned from the past and don't just build web-pages for one browser only. This is not true in practice. Just a few days ago I couldn't use clippercard.com on Firefox for Android because the WebKit prefixes broke the design so badly as to be unusable. :( For numerous other examples: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=evangelism https://bugzilla.mozilla.org/buglist.cgi?quicksearch=evangel... > When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle). And if they don't, their pages lock their users into Chrome…
  - BrendanEich 13y ago
    Web developers know too well the trap of testing only on one browser, which when Dart comes to Chrome, will be Chrome. Testing all input data in a space that exceeds the integral domain of double is hard. Murphy says there will be bugs in other browsers when one's app tests "work in Chrome". For a wannabe-cross-browser, wannabe-standard (Ecma has a sorry history of proprietary standards: C#, OOXML) language pushed by a super-rich big company with what? 60 or more engineers on the project, optics must matter. Why not fix the bignum-not-emulated-in-JS bug? It's easy, GWT has BigInteger emulation code in JS lying around the Googleplex. Just plug that in if the code needs it. The obvious risk remains what I cited in HN two years ago: Google letting dart2js be sub-standard, using all its strength and leverage to promote Dart in combination with DartVM, letting users of other browsers "blame their browser" when things don't quite work as well as in Chrome. Given market share among browsers currently, I think this will backfire, but it could inflict collateral damage too -- on developers as well as on users. And it just plain looks bad. People expect better of Google, and they ought to. /be
afsina 13y ago
Please do not spread FUD. From what I see there are some extreme corner cases in Dart->Js behavior and they are well known. Dart team promises to support modern Browsers, period.
ahoge 13y ago
> Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?) Integers work fine up to 2^53 (9 quadrillion and some). There is also a "throw_on_javascript_int_overflow" flag, which you can use during development.