Announcement

Collapse
No announcement yet.

ECMA Is Working On Standardizing Google's Dart

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


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

      Comment


      • #4
        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.

        Comment


        • #5
          Is this even supported by any browsers yet? Chrome?

          Comment


          • #6
            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.

            Comment


            • #7
              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).

              Comment


              • #8
                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.

                Comment


                • #9
                  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).

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X