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

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

  • #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; 12-13-2013, 01: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


                    • #11
                      Originally posted by mark45 View Post
                      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.
                      The first couple sentences are talking about 3rd party benchmarks showing Dart native (not compiled to JS) being slower than JS.

                      Comment


                      • #12
                        Originally posted by busukxuan View Post
                        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. (...)
                        Yes and no. You took me out of context: the Java bytecode is both open and used, but is not used as a web language (the initial point he was arguing for) anymore (even it was used as a plugin). My counter argument is that even a standard bytecode exist (Java), and Java was part of the web, was not adopted. So another open (standard) bytecode will not fix things.

                        Comment


                        • #13
                          Originally posted by ciplogic View Post
                          Yes and no. You took me out of context: the Java bytecode is both open and used, but is not used as a web language (the initial point he was arguing for) anymore (even it was used as a plugin). My counter argument is that even a standard bytecode exist (Java), and Java was part of the web, was not adopted. So another open (standard) bytecode will not fix things.
                          Oops, sry I didn't realize that you were talking only about the web. Anyway, indeed it was not adopted, and the few languages I mentioned that targets javascript as intermediate language appeared much later, with the earliest of them having appeared in 2009 when large js apps have already become popular(except HaXe which appeared in 2005, but they probably supported js only because it was close enough to ActionScript while js was also used for dynamic web pages). Java basically missed the party by being too early.

                          If there were a unified bytecode for js, wouldn't it be better for the mentioned languages to target the bytecode instead of js itself? If Dart defines one, then it would arrive right when the web programming party is starting, and not miss it by being too early like Java did. Anyway those languages are doing fine right now, providing a better compilation target might be nice, but not crucial.

                          Comment


                          • #14
                            Originally posted by busukxuan View Post
                            (...)
                            If there were a unified bytecode for js, wouldn't it be better for the mentioned languages to target the bytecode instead of js itself? If Dart defines one, then it would arrive right when the web programming party is starting, and not miss it by being too early like Java did. Anyway those languages are doing fine right now, providing a better compilation target might be nice, but not crucial.
                            First of all, why should it be a bytecode for JS? Doesn't Asm.js is defining just this? If you need to serialize data, there is Json, which is also standard. JS as far as I see it should be an easy target to optimize and maybe is not overly compact, still as of today is not so far from Java performance. Most of slowness to not run JS today is mostly memory related (as Java was in the past) or the way lightweight processes are made (there are none, JS being a deeply serial language) so is hard to use all cores.

                            So even if Java (bytecode) will be adopted tomorrow with a specification (would be even easier as Java bytecode is already defined), I don't think it will change the web as for tomorrow.

                            Comment


                            • #15
                              Originally posted by ciplogic View Post
                              First of all, why should it be a bytecode for JS? Doesn't Asm.js is defining just this? If you need to serialize data, there is Json, which is also standard. JS as far as I see it should be an easy target to optimize and maybe is not overly compact, still as of today is not so far from Java performance. Most of slowness to not run JS today is mostly memory related (as Java was in the past) or the way lightweight processes are made (there are none, JS being a deeply serial language) so is hard to use all cores.
                              Asm.js is indeed almost there, it's more like LLVM bitcode, being programmer-readable, yet functions almost like bytecode. If people are targeting it, then why not target bytecode, which is not worse than asm.js?
                              I do agree with you that there shouldn't be a js bytecode now, since retargeting isn't a very convenient or quick job. Having everybody change to a new target + time for coordination is simply too much a trade-off for the slight benefits. There _should have been_ a bytecode. If there had been a bytecode before asm.js appeared, it'd be a different story.
                              However, there isn't something like asm.dart, and if Google wants to increase Dart VM adoption and also maximize performance(which is one of the main reasons to create dart), should it choose to create an asm.dart or define a standard bytecode?

                              So even if Java (bytecode) will be adopted tomorrow with a specification (would be even easier as Java bytecode is already defined), I don't think it will change the web as for tomorrow.
                              yeah it wont be. It has practically no integration with the DOM.
                              Last edited by busukxuan; 12-13-2013, 11:46 PM. Reason: Added the last sentence.

                              Comment

                              Working...
                              X