Calling it “politics” is a disservice. PNaCL was closely tied to Chrome (+ PPAPI), but it paved the way for WASM. Mozilla’s asm.js was a different step leading in the same direction.
Eh, PNaCl had its own share of problems (the only feature it had even over asm.js was pthread-style threading, but performance was about even and first time upstart speed for a new code blob was a lot slower both than asm.js and Wasm).
But as the "whole developer package", PNaCl quickly fell behind emscripten:
The whole feature area of interacting with the Javascript and web-API side was basically non-existant, or at best difficult (it felt more like JNI in the Android SDK/NDK), while emscripten treated this as important feature to get right from the start.
Emscripten realized early how important it is to support porting existing code bases and added shims for quite a few popular cross-platform APIs.
Working with the PNaCl SDK was just barely better than the Android NDK (which is pretty much the yardstick for the worst developer experience possible), and development just wasn't as fast and "pragmatic" than emscripten and asm.js (despite emscripten basically being a "one man show" for a long time).
WebAssembly is so much better than the migration documentation from PNaCL into WebAssembly is full of "Not Implemented", "In future HTML 5 API", "Being worked on", ....
The irony of all of this, it that Chrome and Safari (mostly due to iOS) are what most developers nowadays care about, so we might end up with WebAssembly that works best on Chrome, coming full circle.
And the current WebAssembly development experience is also not something to be proud of, see Ashley Williams talk at WebAssembly Summit.
I do agree about the sore state of Android NDK, despite many improvements in the last 10 years, to the point that I think by making it such an unbearable experience to use C and C++, it is one of the mechanisms Google uses to improve Android's security.
