There are other paths for Haxe, although they are probably not pretty. That is Haxe -> C++ -> Emscripten -> asm.js. Then there is another, Haxe -> Java -> GWT -> JS.<p>I think Haxe is underappreciated for areas other than game development. You can write serverside logic with it (compile to js for node.js, php, neko, java, c#, python), and target flash and js in the browser.
Haxe + Flambe really is a nice combination for developing 2D games for us at the moment. We cover old browsers with Flash (IE6 etc.) and modern browsers - either canvas or WebGL, with almost no concern about which ends up running in the end on the client. It almost feels like magic at times. The compiler also generally seems very fast as well.<p>Sublime text makes a nice(ish) IDE with free plugins.<p>Additionally, we can relatively easily compile out iOS and Android binaries should we want/need to. It's a very nice system to work with and has caused us very little problems with just getting things done.
> A lesson to future compiler makers: if you want your compiler to be really fast use OCaml, not Java!<p>Another option the author could have explored is js_of_ocaml. It compiles OCaml bytecode to JavaScript. It works quite well in my (somewhat limited) experience.
GWT is still a very viable option for writing JavaScript applications, if not actually the best one. It is one of (or the?) first transpiling tools and very mature and feature rich (transparent RPC/serialization, obfuscation/deobfuscation, IDE integrated debugging, i18n, resource bundling, code splitting, JavaScript interoperability, etc.).<p>The author seems to have a bit of a bias (Dart's designers "ate too much Java for breakfast"), but Java is rock solid, and being able to write the entire application, from the client and the domain model on down to the backend, is a major boost. GWT also has a vibrant community (see f.ex. the GWT.create() event across US and Europe: <a href="http://gwtcreate.com/" rel="nofollow">http://gwtcreate.com/</a>) and lots of invention and development going on, with a huge new release (2.7) coming up.<p>See my game project for an example of GWT in action: <a href="http://www.webworks.dk/html5engine" rel="nofollow">http://www.webworks.dk/html5engine</a>
> <i>I don't know how exactly Emscripten handles the uints question but everything worked well and pretty fast without me having to worry about it and having to turn uints into ints.</i><p>Isn't that a bit cheaty? IE is potentially a lot faster with that change, which Haxe's port benefits from. Haxe's port got more work put into, so proclaiming it a winner because Emscripten was already pretty fast without any work put into the port makes me doubtful of the results.<p>(Also, Haxe's UInt 0xFFFFFFFF not being converted to -1 sounds like a bug waiting to happen.)
Haxe's compiler speed probably isn't from OCaml, and rather from a much simpler compilation process than is necessary for Dart or emscripten.
For Dart, it wasn't fully valid. The problem was that they used the 32-bit VM on a 64-bit machine. Of course, the Dart team is working on fixing the number boxing on the 32-bit version that resulted in the poor performance, but the 64-bit performance would've been better, as outlined in the article.