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.
Yes, but emscripten can compile to both (with or without using the new native LLVM WebAssembly backend). It's stretching the word polyfill, but emscripten users have pretty close to a turnkey solution for producing code that detects WebAssembly support and falls back to asm.js.
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.
NaCl predates asm.js/Wasm by 2 years: it wasn't always an option
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.
When do you think was a Good time for Google to switch tracks?
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.
> Google had a lot of people working on NaCl and PNaCl for a long time before they started working on WebAssembly
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.
Google makes money from the web. Massive amounts of money. Something like 93% of their revenue. If WebAssembly leads to the decline of mobile apps, the amount of resources that Google spent on PNaCl is so tiny compared to the amount they will make by continuing to own the world of online advertising.
> Just so I get your argument straight, you're saying that launching a proprietary competitor to the standard means you're helping the standard?
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.
Actually a commitment to Web standards does mean a commitment to not launching nonstandard extensions to the Web platform, usually. Many of Chrome's own Web standards people would tell you this. For PNaCl and some other features Google's official excuse was to designate them "not part of the Web platform" ... which doesn't really make sense from anyone's point of view other than Google's.
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!
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.
I am curious what made it necessary to run NaCl in a different process? I thought the main idea behind NaCl was to allow the same-process native sandboxes.
According to https://static.googleusercontent.com/media/research.google.c... NaCl does not sandbox loads, relying on address-space separation to ensure secret data is not leaked. Obviously this only works with a single sandboxed application per address space. (And even then you'd have to be pretty careful!)
This is only for NaCl on ARM or AMD64. The original NaCl for x86 uses the segment registers for isolation allowing to restrict both loads and stores only to the permitted addresses. That, as far as I understand, does allow to embed into 32-bit process without compromising secretes.
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.
Chrome doesn't run V8 in a different process from the page DOM. That's the difference: NaCl/PNaCl _does_ run in a different process from the page DOM, so interacting with the DOM gets complicated.
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.
