Dart is an unilateral project aiming to: "ultimate goal is to replace JavaScript", "rescue browsers from JavaScript" or "Google preps Dart to challenge JavaScript". Being open source here, is not good enough.
Google Chrome has yet to implement the DartVM, I believe the OilPan memory experiment allowing for multiple languages to interact with the DOM without leaks is experimental still.
Secondly, Dart compiles to efficient Javascript and works on all modern browsers.
I haven't seen anything about Dart (the big win would be eliminating the really slow DOM "GC" cycles on the webkit/blink side of things), but it would be interesting if this opened the way for easier VM integration. My understanding was that post-webkit they were tying v8 deeper into blink, though, not allowing more flexibility...
Thanks, yeah, that was my guess too (fix leaks by GCing DOM stuff, which is a nice idea), I was surprised to hear it was related to Dart somehow. I can't seem to find anything online explaining a connection between them (is it just speculation?).
and you can see that saying that asm.js runs faster in a particular browser is just wrong. On many benchmarks Firefox and Chrome are very close.
In the end, asm.js speed is just like SunSpider and Octane and Kraken speed - it's something browsers compete on. That tends to reduce the differences over time, since all the JS engines are very capable.
Dart compiles to just JavaScript that works in all browsers, and if a browser integrates the Dart VM, it'll run faster.
asm.js is just JavaScript that works in all browsers and if a browser integrates an asm.js compiler, it'll run faster.
Yes there are deployments steps needed to serve both Dart and JS to browsers: Those steps are:
1. Include both the JS and Dart in your static resources.
2. There is no 2.
The difference between asm.js and Dart is, as I mentioned before, that it is impossible to serve a Web app with asm.js that does not work in all modern browsers, due to the fact that asm.js is just JavaScript. With Dart, however, if you serve the Dart and don't include the corresponding JS, then your app only works in browsers that implement the Dart VM.
This. Set aside that Javascript has hit "peak speed", its failures for large codebases are fundamental [1]. I don't agree with the Google hate, but I can understand. What I don't understand: outright denial of the possibility of something better than JS.
(for my personal projects, I genuinely love JS)
1 As someone who works in a large organization, I live this. Small groups with great programmers can make use of all the many tools and tricks for maintaining their project, but for teams fractured across time and space and governance, it is no fun.
The "absent browser-manufacturer consensus" limitation in the post suggest that the hope is that a better development platform won't come with the cost of a fragmented web; i.e., that whatever the choice is for improvement (Dart or something else) it won't be one or more vendor-specific targets, but one broadly-accepted target that can be used freely without worrying about either locking-out users of other major browsers or providing different browser-specific alternative s.
That's correct. There is basically nothing comparable between asm.js (which is a subset of JS with a JavaScript interpreter optimized for it) and Dart (which is a language that currently compiles to JS with no special compiler optimizations in any engine that I'm aware of).
When Google starts shipping the Dart VM, then it will be a different story, of course. It will still not be comparable to asm.js, because asm.js runs in all browsers without the site author having to do anything (which would not be the case if Google shipped the Dart VM, as it would then be possible, and convenient, to write pages that only worked in Chrome).
> When Google starts shipping the Dart VM, then it will be a different story, of course.
I've never heard anyone from Google state an intent to ship Dart VM in browser for general use without other browser vendors being on board (Dart VM for running Dart on the server, sure, and Dartium [Chromium with Dart VM] as a rapid-cycle tool for developers, sure), the specific reason being to encourage Dart use by not making it browser specific.
Heck, there's no reason, if asm.js catches on for optimized browser support, the preferred-for-client format of Dart couldn't move from compilation to bog-standard JS to compilation to asm.js.
They are working on changing some internals of Blink project (code name oilpan) so that both Dart and V8 can work better with it.
My understanding is that they will ship Dart VM with Chrome once it is ready regardless of other browsers decision. This will probably be post 1.0 tough.
Only Firefox uses a separate special interpreter (Odin Monkey) for asm.js - Chrome's asm.js improvements come from optimizing the same V8 JS pipeline. Having a separate compilation pipeline can be viewed as a disadvantage since any optimizations for speeding up asm.js doesn't improve JS performance: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
> It will still not be comparable to asm.js, because asm.js runs in all browsers without the site author having to do anything
Dart web apps will continue to run in all browsers just as it runs today through Dart2JS, it even has great source maps support which lets you debug native Dart code even though it's running transpiled JS. There's nothing special the "author" would have to do, it already exists as part of the project template, e.g. if the browser has a Dart VM it will run the Dart code natively, otherwise it will run the Dart2JS version. Since some Dart benchmarks http://www.dartlang.org/performance/ show Dart2JS outperforming handwritten JS in V8 even with the overhead of different semantics, I'm assuming that Dart2JS compiles to efficient JS that developers wouldn't write.
> because asm.js runs in all browsers
runs is a technically interesting term, there are some asm.js demos that you would not attempt to run without asm.js specific optimizations (i.e. not Firefox) since it would be unusably slow. This is visible in the Epic Citadel http://www.unrealengine.com/html5/ flagship asm.js demo where it needs a Firefox Nightly release to run. The demo doesn't let you run it in IE10 and whilst it lets you try run it in the latest Chrome, but it crashes.
Even Firefox ended up reverting a correction fix (deviating from their JS SpiderMonkey VM) in OdinMonkey because it would invalidate its type checker and cause this demo to run with their normal (i.e. unoptimized asm.js) JS engine: https://plus.google.com/111090511249453178320/posts/cr4jTsfx...
So whilst it can in theory technically still run since its "just JavaScript", it can currently be either a broken, or unusable experience if you don't use Firefox.
It is not a separate pipeline. asm.js uses the standard IonMonkey pipeline, with some additional IR-level instructions.
Furthermore, the argument that doing work on asm.js won't help normal JavaScript applies equally well to the Dart VM.
> There's nothing special the "author" would have to do, it already exists as part of the project template
I'm glad to hear that, but the fact that it is possible to just not serve the JS (or, just as badly, not test it: from what I've read elsewhere in this thread, the semantics of Dart2JS is not the same as the semantics in the Dart VM!) doesn't give me confidence that people won't write Web apps that depend on the Dart VM.
The worry is that Web apps will come to depend on the Dart VM being present. I have seen nothing to indicate that this is not a very real possibility.
> The demo doesn't let you run it in IE10 and whilst it lets you try run it in the latest Chrome, but it crashes.
That has nothing to do with optimizations and is a bug in Chrome's JS implementation. The ECMA standard says that asm.js is valid JavaScript.
> I'm glad to hear that, but the fact that it is possible to just not serve the JS (or, just as badly, not test it: from what I've read elsewhere in this thread, the semantics of Dart2JS is not the same as the semantics in the Dart VM!) doesn't give me confidence that people won't write Web apps that depend on the Dart VM.
> The worry is that Web apps will come to depend on the Dart VM being present. I have seen nothing to indicate that this is not a very real possibility.
Dart has always their primary goal to compile to efficient JavaScript:
There have been many times where language features were dismissed because they couldn't be compiled to efficient JavaScript (e.g. non-local returns and tail recursion). Google knows that Dart2JS is an important platform to optimize for (which has great source maps / debugging and tree-shaking optimizations) since it's the platform target that most browsers will be running and they want to ensure their own internal apps built with Dart2JS has a good experience across all browsers.
Following the mailing list, the only known deviation (that's wasn't a bug) is with some corner cases involving its use of arbitrary-precision integers: http://www.dartlang.org/articles/numeric-computation/ which relates from numbers in JS being stored in doubles (IEEE-754).
Other than that it's impossible for web developers to "target the Dart VM", the libraries in the Dart SDK are separated by platform so packages that can only run on the Dart VM like 'dart:io' cannot run on the client. Likewise there are some client packages like 'dart:html' that can only run in a browser and not on the server.
> Only Firefox uses a separate special interpreter (Odin Monkey) for asm.js
Not true, Firefox uses OdinMonkey, which type checks the code, but then optimizes it using IonMonkey, the exact same pipeline all JS code uses.
> runs is a technically interesting term, there are some asm.js demos that you would not attempt to run without asm.js specific optimizations (i.e. not Firefox) since it would be unusably slow. This is visible in the Epic Citadel http://www.unrealengine.com/html5/ flagship asm.js demo where it needs a Firefox Nightly release to run.
This is simply false. You can run the Epic Citadel demo in Chrome (dev runs ok on my machine for example) and non-nightly versions of Firefox.
It is true that the Epic website recommends Firefox Nightly, that is outdated and it should definitely be removed.
> This is simply false. You can run the Epic Citadel demo in Chrome (dev runs ok on my machine for example) and non-nightly versions of Firefox.
I've got the latest version of Chrome and it always crashes for me: http://imgur.com/Nrsxsdk
I've tried it a few times and I've never seen it work in Chrome, It even crashes when I tried it in Dartium (a Chromium based browser shipped with Dart SDK). Though I don't have the dev version of Chrome to try it on.
> It is true that the Epic website recommends Firefox Nightly, that is outdated and it should definitely be removed.
Right, it works in normal Firefox which is what I meant.
P.S. it is good to have 2 from the Mozilla elite here to clarify Firefox internals :)
OdinMonkey is: a separate front-end for optimizing compiler (one that translates JavaScript code to compiler IR), a couple of IR instructions specific to asm.js (e.g. asm.js heap access), plus AOT linker, trampolines for transitioning to/from asm.js code and some runtime infrastructure specific for bounds check elision on 32-bit platforms. Potentially there will also be a separate parser added to the mix.
The code generation back-end and middle end are the same as IonMonkey uses (sans code generation patterns related to added IR instructions).
Overall both start of asm.js code compilation and end are highly customized and different from what happens to normal JS functions.
Whether this constitutes a separate pipeline or not is debatable. I think it does because none of this custom stuff is running for normal JavaScript no matter how you write it until you put "use asm"; in the right place. I am not debating that it is build on top IonMonkey though (my post from April states exactly that).
[One additional thing to notice is that asm.js typing rules are clearly at least partially duplicate what IonMonkey type inference already should infer statically for the JavaScript code, at the same time, if I am not mistaken, there is little sharing going on between OdinMonkey type-checker and TI engine.]
> Whether this constitutes a separate pipeline or not is debatable.
If this comes down to the semantics of "separate pipeline" then maybe that is pointless. There is some new stuff at the start and end of processing, as you say, but all the middle is shared, and that is by far the bulk of the code.
IMO it comes down to the fact that one developer wrote all the new stuff at the start and the end in a few short months. Compared to a team that took years to write IonMonkey and other parts of the JS engine that are shared. So calling this a new VM or new JIT is definitely wrong, and even calling it a new pipeline feels like an odd choice of words, since the "pipeline" used on asm.js code is almost entirely of the existing SpiderMonkey VM.
> The special interpreter is what I've inferred from pcwalton's comment of their being an optimized interpreter for it in Firefox. If its the same JS VM how can anything fail the type checker (e.g. forgetting a '+' or '|') cause it to run much slower?
The type checker either succeeds or fails to type check. If it succeeds, we know all the types and send those with the code to IonMonkey (just like normal code, except with the types). Otherwise, we run it normally, and eventually it will also get sent to IonMonkey (with types inferred at runtime).
So failing to type check can make a difference in performance. It should not be large, and if you look on awfy, on most benchmarks it in fact is not (it is larger on large benchmarks though, which need more attention).
> I've got the latest version of Chrome and it always crashes for me
Yes, this was fixed by the Chrome devs, but not yet in a stable release. Please try the Chrome dev build for example, and you'll see it runs very well there. In just a matter of weeks that will be true in stable Chrome as well.
> Our main cost, running a live game, we managed to completely remove gets and puts and run in memcache. We hardly scratch our daily usage now.
Using memcache for store gameplay data is not the best idea. Memcache could be evicted at any time without any previous warning. Using a backend instance and storing the data in the ram is an order of magnitude faster, and thanks to the runtime environment api the service could stop gracefully.
I agree losing all games in progress is a pain, but our card game is meant to have a 5 min order of time investment, so its not a huge biggie that users occasionally have their games wiped. Annoying 2% of our users is sufferable at the moment
So, I've thought for a long time ... if I could take a clean sheet of paper and write [a new language] that retains all the goodness of [JavaScript] ... I would not have come up with anything like Dart. - Douglas Crockford
I hope so