> There's little reason webkit performance cannot approach that of native, particularly if it used something like nacl rather than js, and no reason APIs cannot

> There's little reason webkit performance cannot approach that of native, particularly if it used something like nacl rather than js, and no reason APIs cannot be exposed to web apps too (Apple exposes quite a few). While I agree with that sentiment, I disagree with the example provided ... if you talk about NaCL, you're not talking about web apps or "the web" anymore. It's not a standard, it has portability issues and it will probably never be implemented by anybody else other than Google. We can bitch and moan about how broken the W3C standardization process is, but the existence of this process is also why the web is open and why it's awesome. The alternative asm.js, while not being an answer to all issues addressed by NaCL, is a much better approach, because it's still standard JS and even if the browser does not optimize for the asm.js instructions set, the app still works - and if it takes off for games (and I believe it will), then all browser vendors will be forced to optimize for it - because it's one thing to not support some plugin (e.g. NaCL) and quite another to have clear instances in which the browser is much slower than the competition and thus directly comparable. For unbelievers that haven't seen asm.js in action, checkout this famous demo that works well in both Firefox and Chrome: http://www.unrealengine.com/html5/ http://www.unrealengine.com/html5/ - that's pure JS right there and I don't think the limits have been reached.