Who knows how fast Emscripten+asm.js-compiled DartVM would be compared to Dart2JS in 2013? I don't know yet, and apparently neither do you. JITs can be tricky, but @azakai is having good results with Emscripten+asm.js'ed LuaJIT2.
What I wrote 593+ days ago was about the Dash memo's Microsoft-like strategy. My point then was not that it couldn't ever be defeated by something like our work on asm.js and Emscripten. Never say never. My point rather was that the Dash strategy intentionally used Google's big resources to push a gratuitously non-standards-based agenda at the expense of its Web-standards-based efforts.
Indeed, since then it has become clear that Google miscalculated. Dart even gave up bignums (the int type) to support Dart2JS/DartVM equivalence, which I think is a mistake. Bignums are actually on the JS standards-based agenda:
Given all the time that has passed since 2010, Google champions in Ecma TC39 could easily have worked bignums into ES7 if not ES6.
At a higher level, by over-investing in Dart and under-investing in JS (the V8 team was moved from Aarhus to Munich and with the no-remoties rule had to be rebuilt), Google has missed opportunities such as game-industry work we announced at GDC with Epic. This is "ok", it's their choice, but I still say that it is inherently much more fragmenting than any optimization of the asm.js kind, and that it under-serves the standards-based Web.
Maybe in a few years we can evolve JS to incorporate whatever helps DartVM beat Dart2JS, if there's any gap left. However, the idea that mutable global objects in JS necessarily mean VM-snapshotting is impossible is simply false. On the other hand, do we really need VM snapshots to speed up gmail startup? LOL!
What about PNaCl? What's the reason you don't support it in Mozilla? It's based on open source tools, and can be easily integrated into any browser.
Your green-colored id says you are new here, and yet unwilling to do basic research in HN on the topic you ask about. I'll take this in the "Dear LazyWeb" spirit, assume that you are not trolling, and give some links. First, one of a few obvious searches:
Back to your comment: "It's based on open source tools" is true of Emscripten too.
The bit about "can be easily integrated into any browser" is false due to Pepper, the large new target runtime for *NaCl. Pepper is a non-standard and unspecified-except-by-C++-source plugin API abstracting over both the OS and WebKit -- now Blink -- internals.
To make such an airy assertion in an under-researched comment makes me suspect that you don't know that much about either PNaCl or "any browser". So why did you make that confident-sounding claim?
These days, large apps are written in JS, even by hand. GWT is not growing much from what I can tell, compared to its salad days. Closure is used the most within Google, and Dart has yet to replace Google's use of GWT + Closure.
Outside Google, hundreds of languages compile to JS (http://altjs.org/). CoffeeScript is doing well still. TypeScript is Microsoft's answer to Dart, and more intentionally aligned with the evolving JS standard.
"Does Mozilla has any plans to improve the situation here?"
Have you heard of ES4? Mozillans including yours truly poured years into it, based on the belief that programming-in-the-large required features going back to "JS2" in 1999 (designed by Waldemar Horwat), such as classes with fixed fields and bound methods, packages, etc.
Some of the particulars in ES4 didn't pan out (but could have been fixed with enough time and work). Others are very much like equivalent bits of Dart. One troublesome idea, namespaces (after Common Lisp symbol packages) could not be rescued.
But ES4 failed, in part due to objections from Microsofties (one now at Mozilla) and Googlers. In a Microsoft Channel 9 interview with Lars Bak and Anders Hejlsberg, Lars and Anders both professed to like the direction of ES4 and wondered why it failed. _Quel_ irony!
As always, Mozilla's plans to improve the situation involve building consensus on championed designs by one or two people, in the standards bodies, and prototyping as we specify. This is bearing fruit in ES6 and the rest of the "Harmony era" editions (ES7 is being strawman spec'ed too now; both versions have partial prototypes under way).
For programming in the large, ES6 offers modules, classes, let, const, maps, sets, weak-maps, and many smaller affordances. I hope this helps. Even more is possible, if only the browser vendors and others invested in JS choose to keep working on evolving the language.
>To make such an airy assertion in an under-researched comment makes me suspect that you don't know that much about either PNaCl or "any browser". So why did you make that confident-sounding claim?
Unfortunately, I can evaluate technologies according only to my experience and knowledge. According to my limited knowledge and experience, what PNaCl evolves to seems like the way to go: I can use whatever language I like to write code; I can utilize resources of computers efficiently; The code is performed in a sandbox; It's based on non proprietary standards (I mean LLVM, not Pepper).
>The bit about "can be easily integrated into any browser" is false due to Pepper, the large new target runtime for *NaCl. Pepper is a non-standard and unspecified-except-by-C++-source plugin API abstracting over both the OS and WebKit -- now Blink -- internals.
It's a new technology, how is it supposed to be standardized? IMO, it's better to create some implementation,
>Have you heard of ES4? Mozillans including yours truly poured years into it, based on the belief that programming-in-the-large required features going back to "JS2" in 1999 (designed by Waldemar Horwat), such as classes with fixed fields and bound methods, packages, etc.
I closely monitored what have been happening to Harmony, and it was obvious that this effort wouldn't have panned out. There were just too many complex features to be implemented (for example, generics) in a single release.
>These days, large apps are written in JS, even by hand. GWT is not growing much from what I can tell, compared to its salad days. Closure is used the most within Google, and Dart has yet to replace Google's use of GWT + Closure.
Both Mozilla and Google agree on goodness of LLVM, since both PNaCl, and asm.js toolchain are based on it. Google has solved the problem of efficiently representing LLVM in a platform independent way and safely executing it in a sandboxed environment. Why not create a PNaCl and LLVM based standard to allow, efficient execution of code? Is it so difficult?
Mozilla promotes asm.js as a "standard compliant" way to do the same thing as PNaCl. However, there are a lot of disadvantages in this approach: asm.js is text based and very verbose, binary format will save a lot of traffic; asm.js doesn't provide access to SIMD and multi-threading which are crucial for good performance; asm.js won't work out of the box, it requiress some effort to support on the side of browser vendors, for example, the only browser where Unreal demo initially worked was Firefox nightly build. Is it so hard to find a consensus among browser vendors (or at least Mozilla and Google) in this respect?
What a formatting mess -- I hope you can you still edit your post and put two newlines after the >-cited lines from my post, and the text where you start replying? Thanks.
If I can read through the mess, you seem to be saying you can't evaluate PNaCl, so you'll just make airy and overconfident assertions about it. Even on HN, that doesn't fly. -1!
When I challenge your further assertion that something is "easily integrated into any browser", you switch subjects to arguing for prototyping and developing a complex system before standardizing it. Good idea (but beware the difficulty standardizing it late if simpler evolutionary hops beat it in the meanwhile; more below on this). However true, that is a dodge, it does not excuse your assertion about "easily integrated".
Doubling down by citing "the DOM" as if Pepper were only about OS and DOM APIs, or as if even just the DOM implementations in different engines had enough in common to make interfacing from native code (not from JS, which is hard enough even with a decade+ history of written standards and market-driven interop testing) easy, just repeats this bad pattern. So -2.
Then you seem to confuse ES4 with Harmony (which I made clear came about after ES4 failed). -3.
At this point on USENET, you'd hear a plonk. But I'll close with one more point:
Mozilla and Google using LLVM does not equate to standardizing PNaCl. Pepper is one problem, a big one, but not the only one. Consider also the folly of using a linker-oriented intermediate representation for a shelf-stable Web-scale object file format. See Dan Gohman's "LLVM IR is a compiler IR" post:
Shortest-path evolution usually wins on the Web. Trying to standardize PNaCl -- including Pepper and LLVM IR abused or patched into shape as a long-lived object file format -- is an impossibly long, almost exclusively Google-dependent, path.
Extending JS among competing engines whose owners cooperate in Ecma TC39, via a series of much shorter and independently vetted and well-justified (by all those engine owners) path-steps? That is happening in front of your eyes.
You may not like it. You may want to say "Go home, evolution, you are drunk":
>What a formatting mess -- I hope you can you still edit your post and put two newlines after the >-cited lines from my post, and the text where you start replying? Thanks.
Sorry, for the bad formatting, when I understood that it's broken I wasn't able to edit it.
>At this point on USENET, you'd hear a plonk. But I'll close with one more point:
I didn't want to argue with you, I just described how it looked to me (and I mentioned it in the previous comments). I just have no expertise here and now see that there're problems which aren't mentioned by googlers in their presentations. May be you are right, may be they are right. I am sorry if I offended you.
>Shortest-path evolution usually wins on the Web. Trying to standardize PNaCl -- including Pepper and LLVM IR abused or patched into shape as a long-lived object file format -- is an impossibly long, almost exclusively Google-dependent, path.
Not looking to argue, just add some value: you say "too much time until it happens" and I've heard that before, many times -- most recently re: Dart (see that Channel 9 Lars&Anders interview).
Funny thing, it has been years since Dart started, ditto PNaCl. Who says JS is the slow path? I suspect it will get there faster (for tangible definitions of "there", e.g., a Rust2JS compiler for you) with well-focused work.
Pretty please! Excited to see pcwalton's zero.rs work, which I understand to be a prerequisite for a Rust2JS. But deeper JS integration than emscripten currently provides (e.g., mapping rust structs to harmony binary data StructTypes?) would be even more awesome. When are you going to land 749786, anyway?
Re: Dart and PNaCl--they've been useful for providing political cover to people who want to evolve JS more aggressively.
Heh, I really do need to land int64/uint64 support. The patch needs tests and some cleanup first. This week may afford some hacking time (finally) instead of just rebasing time.
In theory it shouldn't be necessary to mal-invest in long-odds/single-vendor (and therefore hard to standardize without dominant market power) innovations at high cost, just to drive minimal investment in evolving the web in shorter-odds ways. Especially when the same company is collaborating in TC39 to evolve JS, and owns the V8 engine!
So therefore I dont like asm.js either. I much prefer LLVM or PNaCI. But that is in an ideal world. In real world i would have to agree asm.js seems the way forward. Even with asm.js being a shortcut, it would still take many years for it to gain enough traction and improvement to be really useful as an universal compiler target. Much like what is currently happening now with JVM. Except almost everyone already has a JS Engine Installed, no need to download a Java Runtime.
That way everyone can really use what ever languages that love or they want. With Everything2js.
May the day of languages independent web come faster.
Some days, I hate JS too. But hate leads to the dark side. It is what it is. Might as well hate endosymbionts who power our cells for being ugly.
We're all over performance, including SIMD. Multiple approaches but definitely up for the Dart-like direct approach. Talking to John McCutchan of Google about lining up JS on this front so Dart2JS has a complete target.
You can't simply asm.js'fy LuaJIT2 because it has an interpreter hand written in assembly and it generates native code to achieve peak performance. You can only asm.js'fy a normal Lua interpreter which is up to 64x slower than LuaJIT on benchmarks, when compared natively. So asm.js'fied Lua will be up to 128x slower. Does not sound that impressive...
Hi -- you make a good point, the one seemingly at issue in this tangent (but not really the bone of contention).
As noted, I don't know which will ultimately prevail in pure performance: DartVM or Dart2JS on evolved JS. In the near term, of course DartVM wins (and that investment made "against cross-browser standards" was the strategic bone of contention 594 days ago).
I do know that in the foreseeable term, we browser vendors don't all have the ability to build two VMs (or three, to include Lua using LuaJIT2 or something as fast, in addition to JS and Dart; or more VMs since everyone wants Blub ;-).
The cross-heap cycle collector required by two disjoint VMs sharing the DOM already felled attempts to push Dart support into WebKit over a year ago. Apple's Filip Pizlo said why here:
Other browser vendors than Apple may have the resources to do more, but no browser wants to take a performance hit "on spec". And Mozilla at least has more than enough work to do with relatively few resources (compared to Apple, Google, and Microsoft) on JS. As you've heard, asm.js was an easy addition, built on our JIT framework.
So you're right, an optimizing JIT-compiling VM is not easily hosted via a cross-compiler, or emulated competitively by compiling to JS. LuaJIT2 would need a safe JIT API from the cross-compiler's target runtime, whether NaCl/PNaCl's runtime or Emscripten/asm.js's equivalent.
Googling for "NaCl JIT" shows encouraging signs, although the first hit is from May 2011. The general idea of a safe JIT API can be applied to asm.js too. In any event, one would need to write a new back end for LuaJIT2.
Bottom line: we're looking into efficient multi-language VM hosting via asm.js and future extensions, but this is obviously a longer road than C/C++ cross-compiling where we've had good early wins (e.g., Unreal Engine).
Furthermore, these are microbenchmarks. Large codebases might paint a different picture.
I am also not sure why LuaJIT is the most interesting comparison. Yes, LuaJIT is a work of art, but even normal Lua is quite fast, beating Python and Ruby easily. So even a half-speed Lua-VM-in-JS would be competitive with other dynamic languages - which means it is fast enough for many uses.
Finally, we can certainly compile VMs that JIT, we just need to create JIT backends for them that emit JS (preferably asm.js). But LuaJIT is more tricky, as you note, because it lacks a portable C interpreter.