Looks like Mozilla won this fight.
When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.
Any operation, like 64-bit adds/muls/divs/etc would have to call emulation functions. It'll be orders of magnitude slower.
In theory a translator could be written into asm.js, but there would still be wasm code that won't run fast, such as 64-bit ints, unaligned loads and stores, bitcasts, and other operations.
PNaCl vs WebAssembly was all about letting everybody run sandboxed native code in the browser without any extensions or prompts.
Native Client (the portable version known as PNaCl) was an open source project by google to achieve native performance with sandbox security.
Mozilla wanted a more open web which led to Web Assembly.
PDF.js is at a very comfortable nexus of compatibility and efficiency, and I kind of wish I could use it for non-web-PDFs as well (but not so much that I want to put it in an Electron wrapper).
I'm not personally familiar with those internals, but from my past life in the print industry it took decades for print controllers to reliably handle native PDFs. And it's still not a sure thing[0].
And it's not a stationary spec, it's in Adobe's best interest to keep throwing in new features so they can license new versions of their software. It's literally a rehash of the old school office suite document formats.
Google is willing to cover those development costs because they need it for Android, ChromeOS, and Google Docs. So let them pay for it. This is doubly true if (as I suspect) this becomes the de-facto FOSS PDF implementation.
0: https://arstechnica.com/information-technology/2017/05/micro...
"As I mentioned elsewhere, there haven't been any full time mozilla devs on PDF.js for quite awhile. I'm not sure I actually see the whole maintenance cost savings argument since PDF.js has practically cost Mozllia nothing the last few years. A lot of bug fixes have come from unpaid contributors in that time. Initially, PDFium was pitched as a freebie if we added support for chromium's flash and then we'd also get improved PDF printing and form support. However, the amount of effort that has gone into supporting PDFium is already far beyond what it would have taken to improve PDF.js form support and help improve Firefox's printing (which would have benefited the web in general). Though, this is my very biased opinion as I was tech lead of PDF.js."[1]
And this has been borne out--Project Mortar was announced about 9 months ago, and if you look at the relevant bugs in bugzilla, they are still pretty far away from getting it into production. They could have used a fraction of those resources to get pdf.js at parity with pdfium.
I am referring to the initial offering of Native Client for inclusion into FireFox.
Since this did not happen, Native client did not see the uptake it needed— and the team was destaffed.
Since it was a working platform that actually existed and let you use a modified version of LLVM, it was quite usable.
We could of have powerful native sandboxed apps quite a long time ago if FireFox became PNaCl compatible.
Instead, Mozilla envisioned that the JIT could eventually bridge the native performance gap.
Mozilla defended this ideas such as ASM and emscripten. And now Mozilla is coming close to a more open and performant web.
Mozilla put together a small team and did asm.js to show that you could port C/C++ apps to the Web and get good performance while reusing the JS engine and all the existing Web platform APIs.
Now we have WebAssembly, which uses existing Web platform APIs and which browser vendors are implementing by reusing the guts of their JS engines. It's obvious who won.
In a way it doesn't matter "who won" because as you say Web developers are the ultimate winners. But it does underscore how much the Web continues to owe to Mozilla.
(It's also an illustration of how powerful companies can commit massive blunders and get away scot-free in the marketplace and in PR.)
That's a strategic victory for Google.
But it did lead to a web standard, even if it didn't become one. And in the interim, it provided utility to Google.
> Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.
Yeah, you've mentioned that quite a few times. So what? Unacceptable nonstandard moves are a big part of what stimulates standards progress.
Because then we owe Microsoft and Apple a shitload of thanks.
No, I'm saying that launching a nonstandard solution to a problem without a standard solution or where there are discontents with the standard that are not being addressed is the usual way new standards are motivated, whether the new standard is based on the nonstandard solution or developed in reaction to it.
Standards (and even moreso, standards that are actually implemented rather than being mere paper triumphs) somewhat backward-looking rather than out-of-the-blue.
A commitment to standards isn't about not implementing nonstandard things, it's about engaging in the standards process to help get to a robust standard and then implementing it (replacing nonstandard solutions, if any) when it is clear what the consensus standard will be.
(And I use "nonstandard" rather than "proprietary" because standard/nonstandard is a different axis than open/proprietary.)
> Because then we owe Microsoft and Apple a shitload of thanks.
Well, yes, a lot of current web standards were originally either nonstandard solutions from Microsoft or Apple or alternatives developed in response and motivated by such nonstandard solutions, so, sure, they've driven a lot of the progress. I think they've generally been less good about (at last, slower) participating in standardization of an alternative when their original solution isn't acceptable to other players, but they have definitely been change drivers.
In this case, the desirability and feasibility of running C/C++ code on the Web was not something that needed to be demonstrated by enabling PNaCl for Web content. In fact, uptake of Web-PNaCl has been extremely low --- fortunately. If significant Web-PNaCl uptake had been a prerequisite for WebAssembly, then WebAssembly probably wouldn't have happened!
Google has been doing this for a long time, I doubt it's unintentional. If there is functionality that they want which is not standardized, they go ahead and implement it. When a workable standard is ready or detailed enough, they switch over to it. The earliest instance of this that I can recall was Google Gears, which was deprecated by LocalStorage. There probably are earlier examples.
Here's a timeline:
2011-10-16: Native client released
2013-03-21: asm.js released
2013-06-25: Firefox 22 released with asm.js support
2013-07-17: Chrome 28 released with optimizations for asm.js
2015-06-17: WebAssembly released
2017-06-30: Google announces switch to Wasm.
... in a non-standardizable way.
Why not try to help create a standard instead? What's the benefit of starting with a dirty approach and deprecating it later?
They do that as well, it's not one or the other. Google had employees working on WebAssembly (along with Mozilla, Apple and Microsoft). Standards take time to be developed and finalized.
That's probably because NaCl(2011) and PNaCl predate WebAssembly (announced 2015). Google was optimizing Chrome for asm.js as far back as Chrome 28 (July 2013) - less than 5 months after asm.js was announced.
So as a speculation in an alternative world where Google has not developed Pepper, but bridged web api into x86 NaCl, the latter designs for x64 and ARM would restrict loads only from the allowed address space.
Sure, (P)NaCl could have been implemented differently in a way that allowed multiple sandboxed applications per process, and then DOM access would have been easier and maybe Pepper wouldn't have been necessary, though there would have been slightly higher overhead I guess.
That's all history now.