Mozilla 扔掉Pepper的原因看起來也很簡單：它更希望HTML5標準化來解決一切。比如用WebGL來取代Pepper的OpenGL/ES封裝。PPAPI作為本地API的封裝（而不是NPAPI一樣僅僅提供介面），本身就需要一個“到底要封裝什麼”的規範，而這個規範的形成過程跟HTML5的標準化在某種意義上差不多是重合的。作為希望HTML5儘快、盡全面覆蓋的Mozilla（他們甚至為了阻擊NaCl製造了asm.js）選擇全力支援HTML5是很自然的事情。
至於前幾個答案多次提到的NaCl/PNaCl（區別是前者的可執行部分就是本地CPU程式碼，而後者的可執行部分是LLVM IR），它跟PPAPI不能分開去看，這兩者目前是一而二二而一的關係，都是Google獨佔。至於為啥Google作為HTML5領軍廠商卻分神去做這個東東，我想應該是被前景誘惑了吧。LLVM IR是可以透過JIT在執行時轉原生代碼執行的，結合PPAPI作為封裝過的本地API，假設一切都能解決，那麼將既能做到「一次編譯，到處執行」，又可以在所有平臺上都達到本地開發的效能，簡直就是Silver Bullet一樣的存在……不過實際上達到這個效果要求LLVM JIT效率進一步真正提高到原生代碼的速度（09年看評測很多特定測試在效能上已經可以達到甚至超過原生代碼，但也有不少更慢的），也要求對所有平臺都封裝好需要的各種API，需要的開發力量相當龐大。這些年Google縱橫捭闔，藉著準備HTML5標準化的名義裡在各平臺的Chrome瀏覽器裡大肆封裝各種看起來用得上用不上的API（畢竟Pepper封裝後提供一個js介面是再簡單不過的了）我覺得從這個角度看上去就很容易理解了。
總結：HTML5+asm.js和Pepper+PNaCl，這就是該新聞中傳出要拋棄NPAPI的兩大巨頭各自給出的選擇。前者暫時擁有時間，後者也許擁有未來。至於哪個最終會勝出，還是讓歷史來說話吧。
Mozilla 扔掉Pepper的原因看起來也很簡單：它更希望HTML5標準化來解決一切。比如用WebGL來取代Pepper的OpenGL/ES封裝。PPAPI作為本地API的封裝（而不是NPAPI一樣僅僅提供介面），本身就需要一個“到底要封裝什麼”的規範，而這個規範的形成過程跟HTML5的標準化在某種意義上差不多是重合的。作為希望HTML5儘快、盡全面覆蓋的Mozilla（他們甚至為了阻擊NaCl製造了asm.js）選擇全力支援HTML5是很自然的事情。
至於前幾個答案多次提到的NaCl/PNaCl（區別是前者的可執行部分就是本地CPU程式碼，而後者的可執行部分是LLVM IR），它跟PPAPI不能分開去看，這兩者目前是一而二二而一的關係，都是Google獨佔。至於為啥Google作為HTML5領軍廠商卻分神去做這個東東，我想應該是被前景誘惑了吧。LLVM IR是可以透過JIT在執行時轉原生代碼執行的，結合PPAPI作為封裝過的本地API，假設一切都能解決，那麼將既能做到「一次編譯，到處執行」，又可以在所有平臺上都達到本地開發的效能，簡直就是Silver Bullet一樣的存在……不過實際上達到這個效果要求LLVM JIT效率進一步真正提高到原生代碼的速度（09年看評測很多特定測試在效能上已經可以達到甚至超過原生代碼，但也有不少更慢的），也要求對所有平臺都封裝好需要的各種API，需要的開發力量相當龐大。這些年Google縱橫捭闔，藉著準備HTML5標準化的名義裡在各平臺的Chrome瀏覽器裡大肆封裝各種看起來用得上用不上的API（畢竟Pepper封裝後提供一個js介面是再簡單不過的了）我覺得從這個角度看上去就很容易理解了。
總結：HTML5+asm.js和Pepper+PNaCl，這就是該新聞中傳出要拋棄NPAPI的兩大巨頭各自給出的選擇。前者暫時擁有時間，後者也許擁有未來。至於哪個最終會勝出，還是讓歷史來說話吧。