So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither.
> They are even the dominant platforms on mobile.
For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
That's fine for most things, but web content is something that we do want to always be accessible.
It is hard to adopt the strengths of native execution using all the lowest-level tweaks specific to one platform, because that inherently limit portability by definition (and often also security).
I share your goals, but don't think there is an obvious better compromise than the one we are all already making on the web.
If W3C and WHATWG were competent and delivered a viable web application platform, we wouldn't be hiring Android and iOS developers now. Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive.
> JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl.
LLVM IR was also never meant to be a bytecode. But in both the case of JS and LLVM IR, the question is the final result, not the original intention, even if the two are often connected.
> Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive.
PNaCl is not even shipped, so it is too early to evaluate it. But the last benchmarks I saw for compilation speed and performance were mixed.
(NaCl is much more proven, but NaCl is not portable.)
Neither was LLVM IR, if you mean "portable bytecode".
Both asm.js and PNaCl are using the technologies in ways they were not originally designed for.