Seems like they had legit reasons at the time, given the goal of getting games written for it, and the fact that the WebAPI didn't support multithreading nor sy

Seems like they had legit reasons at the time, given the goal of getting games written for it, and the fact that the WebAPI didn't support multithreading nor synchronous for some common operations. I don't know what the reasoning then was, but it seems to me that if you goal is to get games to port C code, it's a lot less re-engineering if you have threads and blocking ops. I've ported multithreaded apps to the web and de-threading them is a major headache. Again though, if there were no pepper, do you really think Mozilla would have adopted NaCL? On a side note, Firefox 27 finally killed the last vestige of NPAPI exports that we needed to make GWT Dev Mode work (side side note: Chrome killed us first deprecating NPAPI). Here's a case where WebAPI equivalents don't work. Not even PPAPI can work. GWT Dev Mode very specifically relied on synchronous access to JS APIs. Point is, shoe-horning everything in the browser event loop is not the ideal location or design for every API. Sometimes you do need something outside the WebIDL bindings.