Originally posted by mark45
View Post
Announcement
Collapse
No announcement yet.
ECMA Is Working On Standardizing Google's Dart
Collapse
X
-
Originally posted by busukxuan View PostMany 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. (...)
Comment
-
Originally posted by ciplogic View PostYes 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.
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
-
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.
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
-
Originally posted by ciplogic View PostFirst 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.
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.
Comment
-
Originally posted by busukxuan View Postyeah it wont be. It has practically no integration with the DOM.
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).
Comment
-
Originally posted by ciplogic View PostIE team said that they are interested into Asm.JS
Comment
-
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.- 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~
- 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:
- Provide code mapping between source code and bytecode, and disassamblers to support the mapping.
- 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.
V8 and SpiderMonkey has GC already, not sure about others though.
Comment
-
Originally posted by busukxuan View PostYeah, 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).
(This isn't a reply that is specifically to you, I just picked one spot in the performance discussion thread.)
Comment
-
Originally posted by busukxuan View Postasm.js 2.0? sounds great~ hope there will be
V8 and SpiderMonkey has GC already, not sure about others though.
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:
and reading it you will understand somewhat what Asm.JS is and it is compared with an open bytecode (here the curated LLVM one).
Comment
Comment