One could also argue that asm.js's advantage is technical, and it's called "backward compatibility" :).
1. I don't know how helpful open source is if that source is inscrutable. The JS generated by Emscripten isn't super useful.
2. The only reasonable way to use a non-JS language with asm.js is to use Emscripten to compile its runtime or compile a "native" binary. One of the arguments against PNaCl is that you basically need to use Google's implementation. While the tie-in with asm.js is for developers, whereas the tie-in with PNaCl is for users, I think it's tie-in nonetheless.
3. asm.js is billed as an 'open platform', but it's still limited to platforms that can run browsers with asm.js optimizations implemented. The number of these platforms, when you consider phones, consoles, appliances, and legacy platforms, is pretty small. They can also ill-afford a 50% speed decrease. Since this is basically Windows, Mac OS X, and Linux, your native applications are going to work just fine on those platforms. Sure you might have to do some platform abstracting, but not tons, and especially little if using something like Unity.
1. Asm.js is not an alternative for a hypothetical high-performance, human-readable language in the browser. Ex: It's not competing with the idea of a C#-in-HTML JIT compiler. It is competing with Silverlight -where the browser is already downloading inscrutable binaries.
2. Emscripten has so far received the most man-years of effort, but the idea of other systems using asm.js as a compilation target is very attractive and it's not so difficult as to be a huge barrier for competition. For example https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ (for a specific benchmark, after jit warmup). Personally, I'm excited about the idea of hooking the emscripten backend into http://terralang.org/ Terralang is a system for building custom, high-performance languages on top of LLVM.
3. Asm.js runs on any standards-compliant JS interpreter with no special support required. Even if the interpreter ignores the "use asm" directive, you can expect to see speed benefits simply from the fact that asm.js code is JS in a style that is easy to JIT very well. In order for phones, consoles, smart TVs ect... to fully benefit, it will of course require the platform holders to put in the effort to respond to "use asm". "Open Platform" doesn't mean "Works perfectly before the platform holder even implements it" ;) Also, Asm.js is not targeted to compete with native, installed executables. It is just trying to get the capabilities of HTML apps on all platforms to be closer to those of native executables.
I disagree that asm.js isn't trying to implement '<script type="text/lua">', and is only interested in unseating Silverlight/Flash. Alon Zakai argues for asm.js becoming the bytecode format of the web, and advocates for compiling the runtimes of other languages to JS using Emscripten.
2. I read about PyPyJS a while ago, the way it works is by compiling the PyPy interpreter into JavaScript using Emscripten. I don't think you'll ever see TerraLang ported because it relies on LuaJIT. AFAIK, every large user of asm.js uses Emscripten, because asm.js is such a bear to work with manually. That's fine, but to me (again), lock-in is lock-in. I'd be really surprised to see a non-LLVM solution crop up.
3. I think "runs" implies some level of acceptable performance. Try running asm.js code in IE, for example. Even in browsers that have a lot of optimizations (asm.js-specific and not), performance varies between 1.5x-2x of Firefox', and 3x-4x of native code (http://arewefastyet.com/#machine=29&view=breakdown&suite=asm...). This is still impressive theoretically, but pragmatically that's a huge performance hit. It's also important to remember these are very current browsers on very current platforms, and you're assuming a lot of other things, a fat network pipe to download a huge JS blob among them.
For example, I could run a PlayStation emulator on my phone and barely get a proper framerate. If you put this same emulator in asm.js using Emscripten, it would run half as fast at best (in Firefox), and we haven't addressed all the other problems with HTML5: skipping audio, high latency on input (mouse, controllers), networking performance, etc.
Or for another example, let's say I can play Call of Duty 5000 on my new PC at 60 FPS. Handwaving a lot, let's also say I can play Monster Madness on the same PC at 30 FPS, because of the 50% drop due to asm.js. But let's also say I bought a laptop a couple years ago that runs CoD 5k at 30 FPS, but Monster Madness runs at an unplayable 15 FPS. You can argue, "just run the native version!". But at that point, why am I bothering with asm.js at all? To avoid installations? While that can be important, I'm not sure it's worth millions of man hours and dollars.
(I know Monster Madness is nowhere near as demanding as a hypothetical Call of Duty 5000 would be, but I hope you get the point I was trying to make)
To summarize, asm.js enables zero-install, sandboxed, cross-platform applications at a huge technical price (even though you're technically installing the app every time you load it up, caching excepted of course). I'm not at all convinced we can't achieve the same goals in a much simpler way.
---
Finally, we haven't even begun to discuss the security implications of running untrusted software that can be modified in transit. I know it's kind of a rabbit hole (computers aren't born with all the software you need installed, it has to come from somewhere). But I do think when we're talking about communications applications, banking applications, the potential insecurity of zero-install apps is troubling.
People ship nonfree, minified JavaScript all the time, and "open source" doesn't mean "only distributed in the form preferred for modification". I don't see how this is unique to asm.js, or even that important: you can just put a link back to the "real" (e.g. C++) source in a comment on the page you serve.
I do think you've hit on something though:
> People ship nonfree, minified JavaScript all the time
I know, and I think it's dangerous for software freedom if the apps we start depending on are all closed-source web services, where we're at the mercy of the owners. Vendor lock-in is vendor lock-in, no matter the distribution channel, and zero-install isn't worth it.
Emacs is free software and people typically download a binary to use it. Is that dangerous somehow? The source code is in a well known location.
I agree that it is troubling that nonfree JavaScript is shipped all the time, but again, that happens every day without asm.js being involved, and asm.js does not help or hinder this.
The main reason free software saw such adoption was that it was very high quality software available for free. Most people aren't even aware of the philosophy and history behind it, nor would they base their decision on what software to use on that philosophy and history.
Web services aren't covered by free software licenses, but they generally have no cost, are sandboxed, and you don't have to install them (even though you're actually "installing" them a lot, just in the background). For almost all users, that's a huge win, but for free software, that's a huge loss.
asm.js enabled many more classes of software to run in this environment, and I think that's a big looming negative for software freedom. I love Mozilla and I think what they do is amazing on almost every level. But the web is more than just a browser and JavaScript. There's 65k ports and dozens (hundreds?) of protocols. There's no need for the battle for the open web to take place only in the browser space.
But, you need people to download and install your app in that case. The reason major game companies are investing in asm.js ports, even though their engines work great natively, is because the web is a very good distribution platform. That's really all there is to it - no one controls the web, there's no charge to ship a game there.
I also think pouring millions of man hours into a transpiler and JavaScript engine optimizations is probably the least efficient and most convoluted way to take advantage of the web as a distribution platform. I think the way this should all be framed is, "it would be better if browsers supported a lower-level bytecode, or more languages, or both, but that's politically impossible to achieve, so we have asm.js". That's the only thing that makes sense to me here.
Perhaps Microsoft will tier their products in a different way. A Office 360 subscription (or whatever it is branded) will get you access to Office, running in a browser, under asm.js. Perhaps they'll do something different. Sooner or layer, however, the Microsoft embrace of this technology will be monetized.
There are side-effects. Microsoft can sell tools that now run a tranpiler to put executables on the web. They might or might not use LLVM to that end.
This development means that asm.js has become a defacto standard. It is too soon to tell if this will be more widely adopted, as defacto standards fail al the time. I think, however, that this one will stand. Quite likely we all are now going to be freed and constrained by small design decisions made long before this adoption came to pass.
2. ASM.js is for low level code, the kind of code that doesn't do garbage collection. As far as high-level languages go, Javascript has pretty good performance, is very flexible and can be used as a target by compilers without necessarily needing ASM.js. Examples of languages that are very different from Javascript, but with compilers targeting Javascript and doing it quite well - http://www.scala-js.org/ ; https://github.com/clojure/clojurescript
I personally do not get why developers would want PNaCl, as PNaCl will never be a standard, for the same reason SQLite never made it as a standard storage in HTML5 either. If you want anything other than what the browser standards are capable of, then you're free to go native - because here we can have a discussion about why the browser as a platform has gotten so ubiquitous in the first place ;-)
3. You're mistaken - Asm.js compiled code can run even in browsers that do not have special support for Asm.js. Yes, that code will be slower, less efficient, but it still runs. Also, what limitations does Asm.js has that prevent it from being implemented on all platforms?
2. Well if they don't target asm.js, I'm not sure how relevant they are to our discussion. They're going to get faster as JavaScript engines become more optimized. I tried the Scala.js benchmark, and at 1000x1000 and 1 pixel, it took over 10 seconds to render the scene. I don't know what that means, but it felt slow. I can't find comparisons of Scala/Clojure in JavaScript to Scale/Clojure on the JVM, if you know of some, can you point me there?
PNaCl won't be a standard because of politics. Technologically, it's superior.
3. It "might" run. If you depend on WebGL you can kiss IE support goodbye, for example. Also "run" ought to come with some sort of baseline performance. Let's say you can run Windows XP via Emscripten. Don't you agree that the attendant speed decrease means that, while it may "run", it's not very useful if you can't really use it?
Slower than an asm.js-optimizing browser, faster than idiomatic JS.
Suggestion:
WebGL 2 and better WebGL support - Vote in the "IE Suggestion Box": https://wpdev.uservoice.com/forums/257854-internet-explorer-...
By 2012, most of what's in ES6 had rough consensus on; TypeScript was just implementing what was going to be in ES6, rather than ES6 taking it from TypeScript.
But, this here is exactly why I changed my tune. The primary advantage of asm.js is not technical. It's political. It would work without requiring Apple or Microsoft to take any stance at all. The big, slow, stubborn players did not need to be convinced to make any investment of any form. And once it worked, it would not be embarrassing or risky for them to join the party late.
And, here is the evidence that asm.js is working where no other option would. I look forward to the day when we can move on from JS to a better-designed VM. But while I wait, I'll be satisfied for a while with asm.js (once the SIMD support goes mainline).