> Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance.
Older versions of IE won't run normal JS fast either. I hardly see why this is a problem.
> Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases.
Are you aware of how asm.js is actually designed to function? In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.
> In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.
Doesn't it also has to be valid JS with the same semantics? That has to be a pretty significant constraint surely. It's not like being free to define a runtime and then sending the bytecode as JSON or something. Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all that closely to the native code for any particular processor. That would put it on about the same level as PNaCL, which is (or at least was) supposed to be the slower fall-back version of NaCl, rather than "native Native Client".
> Doesn't it also has to be valid JS with the same semantics?
That's correct, yes.
> That has to be a pretty significant constraint surely.
I don't think it's a terribly problematic constraint. Anything that can be done in C can be done in JS.
> Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all that closely to the native code for any particular processor. That would put it on about the same level as PNaCL, which is (or at least was) supposed to be the slower fall-back version of NaCl, rather than "native Native Client".
This is true. It's not quite native code or assembly, but it's very close. I suppose asm.js is better compared to C than it is to assembly.
NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will. You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs.
Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you want to add another variable, which is they don't even get to control how their code is compiled before it runs. It's a recipe for a customer support headache.
> NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will.
It's not a false expectation that asm.js code runs on IE, because it does. It doesn't run as fast as in Firefox, but it runs. It runs in Chrome too.
> You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs.
At least going by benchmarks, asm.js is very much usable in non-Firefox browsers, such as Chrome and IE11. For many applications, 100% of native performance isn't needed... if it's 3x slower in IE, then it's not a problem, at least it works. For games, sure, won't run your blockbuster titles, but neither will NaCl just now. It will, however, run plenty of smaller games. The Humble Mozilla Bundle is a good demonstration of this: it works in Firefox, and it works in Chrome
> Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you want to add another variable, which is they don't even get to control how their code is compiled before it runs. It's a recipe for a customer support headache.
I wasn't talking about games, I'm talking more generally. I don't like (P)NaCl because it reminds me of ActiveX: it is harmful to the open web. But if we are talking about games: I don't see why NaCl is really any less of a headache.
Older versions of IE won't run normal JS fast either. I hardly see why this is a problem.
> Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases.
Are you aware of how asm.js is actually designed to function? In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.