[azakai]

The point is that NaCl is not portable, just like a native platform such as Windows.

Nonportable native platforms are there, you can write apps for them. They are even the dominant platforms on mobile.

But the web's entire purpose for existing is to be portable. So you do need something like JS or PNaCl or the JVM. And all of those, due to being portable and secure, impose limitations, such as limiting the native operations that you perform. That's unavoidable. But again, if you don't like that, develop directly for a native platform.

[pbsdp]

> The point is that NaCl is not portable, just like a native platform such as Windows.

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.

[azakai]

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.

[slacka]

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.

[azakai]

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.)

[pcwalton]

> JS was never meant to be a bytecode

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.