Fat binaries are limited, and people will simply provide the parts for the platforms they currently care about, without care for future platforms.
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.
The teams at Mozilla and Google have done an amazing job of improving JavaScript performance. But, I also have to agree with PBS, that Mozilla has a knee-jerk reaction to many of Google’s promising technologies like WebP and PNaCl. Like many HTML5 technologies that are being shoehorned into areas they were not originally designed for, JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl.
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.
I don't think "knee-jerk" is a fair description. Consider the collaboration between Google and Mozilla on WebM, WebRTC, and countless others.
> 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.)
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.