Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: ECMA Is Working On Standardizing Google's Dart

  1. #1
    Join Date
    Jan 2007
    Posts
    15,641

    Default ECMA Is Working On Standardizing Google's Dart

    Phoronix: ECMA Is Working On Standardizing Google's Dart

    ECMA International has formed a technical committee to work on a standard specification for the Dart web programming language that's developed by Google as an alternative to JavaScript...

    http://www.phoronix.com/vr.php?view=MTU0MjQ

  2. #2
    Join Date
    May 2013
    Posts
    56

    Default

    They just should standartize some bytecode/virtual machine and everyone will compile their web-languages to that bytecode.

  3. #3

    Default

    <Insert this link, this link, and "Well, if they were willing to standardize JavaScript..." joke here>
    Last edited by ssokolow; 12-13-2013 at 02:34 AM.

  4. #4
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    400

    Default

    Quote Originally Posted by Szzz View Post
    They just should standartize some bytecode/virtual machine and everyone will compile their web-languages to that bytecode.
    Why bytecode? Wasn't Java's bytecode standardized? And people don't use it still?

    ECMA standardized many things including JavaScript or .Net or Xaml. So I think is natural for them for industry neutrality to have an open standard, so if Google will make tweaks in future will not matter.

    Good job Google, a case when I hear good news from you in the last weeks.

  5. #5
    Join Date
    Jan 2013
    Posts
    256

    Default

    Is this even supported by any browsers yet? Chrome?

  6. #6
    Join Date
    Nov 2013
    Posts
    49

    Default

    Quote Originally Posted by kaprikawn View Post
    Is this even supported by any browsers yet? Chrome?
    It is currently only supported by one browser, called Dartium, which is a special version of Chromium. No mainstream browser supports Dart natively. But, Dart programs can be compiled into Javascript through the dart2js tool. This tool is complete and the concept is similar to the compilers of CoffeeScript(FOSS) and TypeScript(M$). The dart2js-compiled code often runs faster than handwritten Javascript in terms of large programs, but tiny programs(like hello world) compiled by dart2js runs slower, bulkier and more resource hungry than javascript. (the program has to be large enough that the speed advantage overshadows the slow-down induced by the embedded runtime environment)

    IMHO, Google is promoting the language softly, letting people first start to use it and accept it, before seeing if Dart can really become mainstream enough to have the VM embedded into Chrome. If this ever happens, Dart developers might(all just my hypothesis) be encouraged to include an external link that links to the original Dart code, and then Chrome would seek the link out and run the Dart version instead of the compiled-javascript version, to improve performance. This might be done by dart developers until all major browsers include the Dart VM(if it ever happens), by then Dart will be able to run natively on these browsers. However, it certainly wont be easy to get Dart embedded into non-google browsers, while standardizing it may help increase Mozilla's confidence in Dart(Mozilla would still evaluate Dart in many different aspects before even considering to include it, and i respect that), and M$ would most likely only adopt dart when they can't choose otherwise. I'm not sure about opera, but safari once said they(at the time) had no interest in including a dart VM.

  7. #7
    Join Date
    Jan 2009
    Posts
    1,496

    Default

    The last time I looked at the debian alioth benchmarks dart was still slower than js in every case. That's not great since that was touted as A benefit to using dart (much more work has gone into js vms but I'd be willing to wager that the people working on the dart vm have much crossover with the v8 team).
    Obviously this says nothing about its suitability as a language for large codebases, or ease of use, but anything has to be better than js when it come to handling scope (which is too damned tricky).

  8. #8
    Join Date
    Nov 2013
    Posts
    49

    Default

    Quote Originally Posted by ciplogic View Post
    Why bytecode? Wasn't Java's bytecode standardized? And people don't use it still?
    Many people use it. Groovy, Scala, Clojure, and Ceylon all compile to java bytecode. People don't use it for web client side development, and I guess it's about the performance.

    Javascript nowadays is an intermediate language for CoffeeScript, Dart, TypeScript, HaXe, Ceylon, and there is a(or more?) python implementation that compiles to js. Interestingly, Java's original goal to build dynamic web pages is almost entirely beaten by js, while most js apps perform better than java applets, yet js runs from source, and java runs from bytecode, and in theory using bytecodes improve performance. Google claims that Dart is faster than js, and if so, wouldn't dart be faster than java too? This means Google can actually produce VMs much better than java that are designed for the web(but probably not as good as java on the desktop or server), and dynamic languages can utilize the VM's typing system and build implementations more easily, while static languages would not need those features, and would still be able to be implemented on that VM(although an untyped VM probably provides a better performance for static languages). Also bytecodes generally provide more flexibility than non-bytecode intermediate languages, and therefore is better as a compilation target. If js had a unified bytecode, maybe CoffeeScript et al might be targeting the bytecode instead of js already.

  9. #9
    Join Date
    Nov 2013
    Posts
    49

    Default

    Quote Originally Posted by liam View Post
    The last time I looked at the debian alioth benchmarks dart was still slower than js in every case. That's not great since that was touted as A benefit to using dart (much more work has gone into js vms but I'd be willing to wager that the people working on the dart vm have much crossover with the v8 team).
    Obviously this says nothing about its suitability as a language for large codebases, or ease of use, but anything has to be better than js when it come to handling scope (which is too damned tricky).
    Yeah, even now that benchmark still shows dart being slower. However the official benchmarks from the dart page shows otherwise. Since it's the official one, it might not be so trustworthy, but at the very least we can still use the language to write apps and compile it to js. Note that tiny dart2js-compiled apps tend to perform worse than handwritten javascript(smaller it is more ridiculous the overhead, i guess), though large dart2js-compiled apps may go faster than handwritten js(and often so, according to their website).

  10. #10
    Join Date
    May 2012
    Posts
    946

    Default

    Quote Originally Posted by busukxuan View Post
    Yeah, even now that benchmark still shows dart being slower. However the official benchmarks from the dart page shows otherwise. Since it's the official one, it might not be so trustworthy, but at the very least we can still use the language to write apps and compile it to js. Note that tiny dart2js-compiled apps tend to perform worse than handwritten javascript(smaller it is more ridiculous the overhead, i guess), though large dart2js-compiled apps may go faster than handwritten js(and often so, according to their website).
    If you're talking about Dart code compiled to JS and then benchmarked against "native" JS - then it's to be expected.
    If you're talking about Dart code (not compiled to JS) running slower than JS code then it's a problem indeed.

    You seem to mean the 1st point.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •