1. The point I was making is that a lot of asm.js proponents argue that compared to PNaCl, asm.js isn't a binary blob, and is easier to examine and modify. While I agree this is true, I'm not sure how much it matters; it's still very hard to read and work with Emscripten-generated asm.js code. You can write it by hand for improved readability, but that's not a lot of fun either.

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.