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功能的时间表。我们不想急于任何事情，但我们希望首先提供最有用的东西。这是一个社区团体，所以优先事项的确受到参与者的推动。实现将无法一次处理所有功能，但探索并行性良好。