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.
I suppose I should have asked "what does polyfill mean in this context?" Does that term really alias "run [it] on" or is there something more subtle about this term's meaning?
Web developers, bless their hearts, feel uncomfortable with the word "emulate", so they use "polyfill", or sometimes the more general "shim". To some degree, "polyfill" implies that the functionality being emulated/shimmed is functionality that is under some other circumstances is expected to be provided by the browser itself.
There's a high performance asm.js implementation of WASM (converting WASM to asm.js at runtime). ie if a browser didn't implement WASM, but had a JIT which executed asm.js at high speed, it could execute WASM at high speed
There isn't such a polyfill. There is currently no good tool to translate wasm into asm.js (or general JS) on the client. The best that exists is to run the wasm in a wasm interpreter, very slowly.
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.
Project Mortar is different in the fact that it is PDFium and Adobe Flash being allowed via Pepper API — basically it's for sandboxing those current native plugins. This would not be a public web use case.
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.
Yeah, AFAIK PDFium doesn't use PNaCI and Flash will only be around as long as absolutely necessary. The only reason they aren't using PDF.js is because the PDf spec is ~12K pages long and they don't want to throw engineer resources at it anymore.
> they don't want to throw engineer resources at it anymore.
"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'm sad to see PDF.js go. The PDF spec is ~12K pages long, and most of those pages describe things I don't want my PDF viewer to support, like embedded Flash, in much the same way I don't want my browser to support Flash.
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).
PDF.js isn't "going" per se, but its lack of inclusion and development may certainly take wind out of its sails. It should still be possible as a PDF viewer in the browser (as an addon). And I think you can already use it (inside Firefox) to view non-web-PDFs.
I totally agree that we shouldn't be throwing random PDFs at that pile of C++ code, but I'm not sure there is much of an alternative.
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.
How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's asm.js and Google's PNaCl. Also, the team working on WebAssembly are from Mozilla, Microsoft, Google and Apple. The real winner here are users because we now have a standard among all major browsers.
Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which are now going by the wayside.
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.)
There's no blunder: Google had a goal, threw out something, stimulated competition over the precise implementation, and now there is a universally (among browser vendors) accepted solution moving the web in the direction Google wanted.
Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard. Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.
> Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard
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.
The problem was precisely the Pepper, a pile of API that Google thought they could force on everybody, not PNaCl per see. If the initial NaCl implementation just exposed the pre-existing Web API into the native code sandbox without adding anything extra, the story can be rather different and a version of PNaCl could be standardized.
That's true, although NaCl's design made that difficult because the native code sandbox had to be a different process so interacting with the page's DOM would have required IPC.
There's no denying Mozilla played a huge role, but PNaCl was an critical step away from "JS as the bytecode of the web". That approach simply couldn't compete with mobile platforms running on (more or less) native code.