ECMA Is Working On Standardizing Google's Dart

[Daktyl198]

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.

[ciplogic]

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.

[busukxuan]

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.

[ciplogic]

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

[busukxuan]

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.

[ciplogic]

yeah it wont be. It has practically no integration with the DOM.

Bytecodes are by definition low level.

The single advantage of using a bytecode is that you don't need to parse, validate complex code as you get an intermediate representation that gives the same semantics (albeit a different ugly to parse binary syntax). This will reduce the tokenizing, parse times, evaluating time and this translates somewhat to the the startup time of the application.

Java bytecode can integrate with DOM (it does in all Java Xml DOM readers) and it would integrate as easy to a JS machine (that would support Java bytecode). If you mean for "Java integration with DOM tree of page elements", this is also done (as Java FX).

I will not speculate about Dart capaiblity of creating a bytecode or not (I think it should be possible, even standardized, all is needed by a matter of principle is to be defined a bytecode and an AST tree visitor to fill this bytecode), but the issue it would solve, to have a less parsing time when starting Dart code, makes me think that it will be adopted still. Because when you get an error in your Dart based application, you will get a bytecode offset with an error which (imho) is against the spirit of the web.

Also, JS parsers are really fast as of today after 4-5 years of people optimizing Sunspider. If you want a bytecode, try to hope to an Asm.JS 2.0 which expects to give the capability to precompile code (to not have the "hit" of JIT compilation), GC support, and to not forget more browser support, as of today Mozilla, Chrome are supported, but not so much WebKit or IE (IE team said that they are interested into Asm.JS).

[ssokolow]

IE team said that they are interested into Asm.JS

That doesn't surprise me. I seem to remember reading that recent versions of IE already have some kind of asm.js-like optimization backend. Detecting asm.js annotations would let them trigger it predictably rather than via heuristic detection and optimize more aggressively since they have the confidence that it's not their fault if the code proves un-optimizable and the time spent has to be written off as a loss.

[busukxuan]

Java bytecode can integrate with DOM (it does in all Java Xml DOM readers) and it would integrate as easy to a JS machine (that would support Java bytecode). If you mean for "Java integration with DOM tree of page elements", this is also done (as Java FX).

Yeah I meant the latter, I didn't know one can actually access that with Java FX, thanks for letting me know. So "webview1.getEngine().getDocment()" returns the DOM? Also does it provide access to the Browser Object Model, like "window"?

I will not speculate about Dart capaiblity of creating a bytecode or not (I think it should be possible, even standardized, all is needed by a matter of principle is to be defined a bytecode and an AST tree visitor to fill this bytecode), but the issue it would solve, to have a less parsing time when starting Dart code, makes me think that it will be adopted still. Because when you get an error in your Dart based application, you will get a bytecode offset with an error which (imho) is against the spirit of the web.

1. I said "should they", not "will they", so it's just opinion, not prediction. But anyway, this is the answer I have waited for, thanks~
2. True, errors, but debugging should ensure a minimal number of errors(since comprehensive debugging is an important practice, even in languages that don't show much issue with small bugs). There will still be some errors since the correctness of very large apps are hard to ensure. Maybe the following may help:
   1. Provide code mapping between source code and bytecode, and disassamblers to support the mapping.
   2. Include a link(as metadata) of the source code of the bytecode-form program, so that code mapping and debugging can be done in a browser(which should also solve the "spirit of the web" problem).

Also, JS parsers are really fast as of today after 4-5 years of people optimizing Sunspider. If you want a bytecode, try to hope to an Asm.JS 2.0 which expects to give the capability to precompile code (to not have the "hit" of JIT compilation), GC support.

asm.js 2.0? sounds great~ hope there will be
V8 and SpiderMonkey has GC already, not sure about others though.

[Qaz`]

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

We have to keep in mind the amount of research and engineering hours that have gone into js vm's over the last 15 or so years when comparing performance. Js has received _a lot_ of work, and is ridiculously fast for what it is on the vm's of modern browsers. Dart might be slower than js on googles current vm for each of them, but might still be easier to make fast vm's for. A lot of the work done on js might transfer over to some extent, but I think we still need to allow dart vm's some time (under significant use) to mature.

(This isn't a reply that is specifically to you, I just picked one spot in the performance discussion thread.)

[ciplogic]

http://games.greggman.com/game/thoughts-on-asm-js-vs-pnacl/

asm.js 2.0? sounds great~ hope there will be
V8 and SpiderMonkey has GC already, not sure about others though.

Sorry to make another correction for you, but both V8 and SpirerMonkey do not have a GC in AsmJS codes, they have it just for typical JS.

AsmJs does allocate a big "memory pool" in which the objects are allocated by a custom allocator (like malloc, but handmade in every emscripten generated code). You cannot use the main GC as part of asm.js, you have to write your own. Hopefully it clarifies this for you.

Please read the opinion of a developer from the Chrome's team about PNaCl vs Asm.JS and saying that they overlap:

http://games.greggman.com/game/thoughts-on-asm-js-vs-pnacl/

and reading it you will understand somewhat what Asm.JS is and it is compared with an open bytecode (here the curated LLVM one).