But the important thing in working to port the highest-end games is to push the limits of the web platform, so it can be better optimized. Before UE3 was ported, people were - rightfully! - skeptical any such engine would work well on the web at all, and that port helped get to that point (and now to UE4).
Also, note that the 60% is of CPU performance. You also get close to 100% of GPU performance using WebGL. So overall it will be even closer to native speed (depending on how the specific game balances between CPU and GPU).
Most AAA games are GPU-bound, you mean. It's very rare to find titles from indie developers or smaller publishers that come anywhere near taxing a modern GPU -- due in part to the massive expense required to create engines and assets that are capable of doing so.
(Which is also why the AAA game business model seems more and more to be teetering; AAA titles have differentiated themselves via graphics for decades, but the cost of being cutting edge is so high now that if the title sells at anything less than blockbuster rates it's a financial failure.)
Not big issues, I think. The big issue is having a robust ecosystem for all the things like networking, input handling, sound and video.
Meanwhile, all unused IO/network time loads the most likely next to be encountered content (so in most cases the next level). As this happens in the background, the user most likely will never notice the content has to be downloaded first.
Naturally, this leads to another problem: piracy. After all you don't want to create individually encrypted releases per player (doesn't scale for storage), and encryption on-the-fly is also not possible (doesn't scale neither on server nor on client side). So basically you just dump a shitload of data onto a CDN and hope nobody warez's it.
These tech demos are about pushing the envelope, which is needed to make the web a better platform for high-end games.
Running existing software in some convoluted browser-based environment, and giving a worse experience in most ways, doesn't really seem like innovation to me.
I think we could say it was pushing the envelope if the browser experience was superior to the native experience in every or almost every way. But that just isn't what we're seeing with these demos.
Of course, on the other hand it is inferior in many ways. It's just another option for game creators (and other apps too). For some it will be useful, for others it will not, just like consoles are useful for some but not for all, tablets are useful for some but not for all, etc. etc.
asm.js executes according to the ECMA-262 semantics, which are the full dynamic semantics of JavaScript.
This doesn't mean to imply the subset is the entirety of C; it means the subset is part of the definition of C — just like you can say "'int x = 4;' is C", even though it's a (demonstration of a) subset of C.
The JavaScript which happens to be optimised under the name "asm.js" is still JavaScript that executes in any non-optimising runtime, and the semantics with those optimisations and without are the same.
For the consumer it should be no different except they have an easy url to get to it, maybe saves are a url and there is a bit more security in theory if it is through a plugin that is widely used or tool that is widely used (asm.js).
Really this has tried to get going multiple times and really should have. Flash games were huge, Unity web games are coming up. Shockwave games back in 2000ish started it. Being open this is even better because maybe we can see WebGL gaming take off on mobile. 3d games in the browser have changed over time. Quakelive is going desktop client because browsers changing or removing NPAPI for PPAPI (http://www.quakelive.com/forum/showthread.php?34313) so maybe this is a good time to go the asm.js/emscripten route as plugin support is getting disrupted.
What is important is that developers target platforms with certain features and certain frame rates. The devs targeted Firefox and removed a few bushes.
It is very hard to judge game quality based on compute throughput. Its a game not a benchmark.
tldr; Performance hit to native isn't a relevant statistic.
I think Mozilla is marketing this wrong. Triple-AAA titles go for squeezing every last ounce of system performance. I don't think there is anything to be gained to putting a game like Titanfall, which has 5 gigabytes of assets (some UE titles are much bigger and need blu-ray distribution) inside of a browser. Long downloads, long startup, half performance.
But there is enormous value of running casual games with asm.js. Something like Clash of Clans, or Flappy Bird will run just fine. Pitching that asm.js is going to scale games from mobile up through desktop performance I think is overselling things and bound to lead to disappointment.
Rather than believe we're going to get Call of Duty running acceptably on Firefox OS. Let's first settle for CSR Racing, or HayDay.