|
|
|
|
|
by TazeTSchnitzel
4243 days ago
|
|
> 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. |
|
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".