4 ms·
I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't
by jhpriestley 9y ago
I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.
- roca 9y agoI personally told Google people that the Pepper platform API situation was unacceptable to Mozilla years before PNaCl even appeared. That didn't stop them pushing ahead. So if your theory is correct then Mozilla opposition was not strong enough to stop PNaCl development, and not strong enough to stop them exposing it to the public Web, but strong enough to stop them trying to turn it into a proper Web standard. Wasm is only superficially non-JS. AFAIK every browser vendor is implementing Wasm by reusing the optimizing compilers in their JS engines. I think we might see some extensions to WebIDL and Web platform APIs to improve Wasm app performance. We're sort of already seeing that with [AllowShared]. But there's no need to develop entirely new platform APIs, because fundamentally there's no reason calls from Wasm through JS API glue to the browser should be slow; JS API glue can be inlined into the Wasm code, for example.