WebAssembly之後的本地客戶端的未來後MVP

Question

我確信在WebAssembly Post-MVP之後，asm.js將被棄用。即使現在，一些現有的asm.js項目已經開始使用WebAssembly。 JS引擎（V8）也開始將asm.js鏈接到WebAssembly，所以即使舊的項目永遠不會遷移，最終用戶仍然會從WebAssembly中獲得部分優勢。

我的問題是，那麼native-client呢？它沒有在JS引擎中實現，因此可能會成爲問題。即使現在，Native-client似乎也被棄用了。在可預見的將來，原生客戶端是否會完全從Chrome中移除？我很想看到Chrome的二進制大小有所減少。

方問題：

• 線程/ GC/SIMD /異常都包含在WebAssembly後，仍有一些原生客戶端，但WebAssembly失蹤（阻塞遷移）？
• 爲了達到MVP，WebAssembly花費了大約2年的時間，任何一個Post-MVP的預期時間都已完成？
• 看起來WebAssembly組織正在一次性處理多個Post-MVP功能，而不是逐個處理，這不會讓它慢慢敲定其中一個功能嗎？

Answer 1

僅回答側面問題，因爲我不再在Native Client上工作。 Google的計劃本身就是可以代言的，所以我會將其作爲維基。

更新截至2017/05/20 NaCl isn't in glibc。這是支持的原始libc，花了相當長的時間清理和上游。它只被NaCl的GCC工具鏈支持。仍然支持musl libc，它可以與更新的基於LLVM的NaCl和PNaCl工具鏈一起使用。

更新截至2017年5月30日，Chromium團隊宣佈the fate of PNaCl和tentative roadmap of WebAssembly features。

這裏有一個你沒有提到的一些本地客戶端的功能：

• 外的過程，其中有許多考慮的一個錯誤，因爲它迫使異步通信。它允許有保證的地址空間，這對於64位的地址空間來說並沒有什麼好處，並且對Native Client的雙重沙盒設計至關重要。 WebAssembly還沒有流程。
• 阻止和來自JavaScript事件循環，通過postMessageAndAwaitResponse。也被許多人視爲錯誤。
• 有許多API通過Pepper。許多鏡像Web平臺的API。
• 可以通過mprotect做內存保護（雖然執行頁面是有限的）。
• 可以處理POSIX信號。
• 支持計算goto和其他不可約控制流。
• 有一些即時代碼修補支持。
• 支持弱於seq_cst原子。
• 支持內聯彙編，只要它遵循NaCl驗證規則。

不是所有這些都在便攜式本機客戶端，但。有official documentation of differences。

沒有任何後MVP WebAssembly功能的時間表。我們不想急於任何事情，但我們希望首先提供最有用的東西。這是一個社區團體，所以優先事項的確受到參與者的推動。實現將無法一次處理所有功能，但探索並行性良好。