[BlackAura]

The introduction of pepper.js is particularly interesting. It's a re-implementation of (some of?) the Pepper API on top of the standard web APIs, so you can write stuff for PNaCl but also compile it using enscripten for other browsers. Which means you could target both PNaCl and asm.js at the same time.

That also means it's effectively encouraging asm.js adoption, which might give Apple and Microsoft enough of a kick to optimize that. Google seem to already be planning on it (they added some asm.js tests to their Octane benchmark).

It also might be useful if, at some point, other browsers want to implement a PNaCl runtime. One of the main sticking points (aside from the use of LLVM bitcode, which is not something LLVM was designed for) was that it requires the Pepper API, which is huge, and duplicates much of the existing web APIs. Google have the spare engineers to do that, but Mozilla certainly doesn't.

A reverse of that would be useful too - an implementation of the standard web APIs on top of Pepper, so you could re-target an asm.js app to PNaCl. Or some kind of tooling that lets you transparently target both.

Maybe we'll see some kind of convergence thing going on? Wouldn't surprise me too much if they started evolving slightly towards one another. I think it's probable that asm.js will eventually get some kind of compact bytecode representation, especially if it can be implemented as a shim to allow it to load in existing browsers.

[pcwalton]

Yes, I find the possibility of convergence hopeful.

I'd prefer the inverse of pepper.js and deprecation of Pepper. Way back in the plugin-futures days, every other browser vendor rejected Pepper because it duplicated Web APIs and a C binding to the Web APIs would be more useful. To me, Emscripten and pepper.js just shows that this was true. Emscripten provides C bindings to Web APIs, and pepper.js shows that Pepper is effectively equivalent to the functionality the Web APIs provide. So I see no need for Pepper, and I hope that Google will eventually eliminate this unnecessary duplication of functionality.

[haberman]

> pepper.js shows that Pepper is effectively equivalent to the functionality the Web APIs provide

From my reading of it, pepper.js can only support a subset of Pepper's complete capabilities. At a high level, it is missing:

    - threads
    - memory mapping
    - memory protection

There's also stuff like this in pepper.js that clearly demonstrates a lack of parity:

    // The Web Audio API currently does not allow user-specified sample rates.
    var supportedSampleRate = function() {
      return createAudioContext().sampleRate;
    }

Also pepper.js is filled with chunks of code like:

    var FileRef_GetFileSystemType = function() {
      throw "FileRef_GetFileSystemType not implemented";
    };

    var FileRef_GetName = function() {
      throw "FileRef_GetName not implemented";
    };

    var FileRef_GetPath = function() {
      throw "FileRef_GetPath not implemented";
    };

    var FileRef_GetParent = function() {
      throw "FileRef_GetParent not implemented";
    };

    var FileRef_MakeDirectory = function() {
      throw "FileRef_MakeDirectory not implemented";
    };

    var FileRef_Touch = function() {
      throw "FileRef_Touch not implemented";
    };

I don't know enough about these APIs to say whether this is just incomplete or whether these Pepper calls can't be reasonably implemented on Web APIs, but pepper.js seems far from a demonstration that Pepper is "effectively equivalent" to Web APIs.