Comment by haberman | Hacker News Reader

Comment by haberman | Hacker News Reader

I think this and asm.js are both extremely cool. I look forward to the competition this will inspire, and the improvement of both approaches as a result. I say this honestly not sure which one I personally think will be better in a year or two.

I often think of software as "walking a path." What I mean by this is that there are often different approaches to the same problem, and these start out as just basic, undeveloped ideas. But put smart people on it (and I have high regard for both the Google and Mozilla engineers on these projects) and let them refine these ideas over time and you'll learn more about all of the consequences, the fundamental strengths and limitations, of these approaches.

I first had this thought when working at Amazon. I remember hearing an off-hand comment about how S3 and Dynamo, both Amazon projects that started around the same time, started with very different consistency goals (Dynamo: very weak, S3: very strong) but as the details were fleshed out, ended up coming towards each other and both became more moderate.

I think that's extremely valuable knowledge, because it can become part of the body of resources that any future designer can look at. Whenever you have an idea, chances are other people have "walked the path" of that idea (or some variant of it) before, and reading about their experience can help you see down the road and anticipate what practical problems you'll run up against. You might have an idea for how to improve on what the previous designers did, but by reading about their experience you can save yourself a lot of the work they already did.

For this reason, I look extremely forward to watching these two projects evolve and compete, and in doing so, to learn more about the fundamental properties/tradeoffs of this design space.

Thanks for bringing some positivity to the debate. PNaCl and asm.js are timely and they are technically very different. It will be interesting indeed to see how it goes from here.

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.

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.

> 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.

Reply on news.ycombinator.com