4 ms·

> Web developers will realistically not optimize the PNaCl solution. It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility

> Web developers will realistically not optimize the PNaCl solution. It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility mode, and PNaCL is a whole heck of a lot faster than that. > I disagree that this is worth the cost. This is not about "a slavish devotion to JavaScript"; your solution is fundamentally opposed to portability. Users want applications that don't waste their battery, and that perform well. What do they care about architecture portability beyond the devices they actually have? Fortunately, PNaCL solves that problem, too, as a fallback, while still being able to target x86/ARM without compromise.

pcwalton 14y ago
"It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility mode, and PNaCL is a whole heck of a lot faster than that." I haven't seen PNaCl benchmarks. Have you? It is true that the compilers for asm.js are more immature than LLVM at this time, but there's nothing stopping asm.js from reaching that level. Again, it's just syntax. You're complaining about the fact that the code is delivered in a backwards compatible surface syntax and extrapolating that to unfounded assumptions that it must be slow. It's really an absurd claim.