Design: 为什么不是java或.net？

我也是 WebAssembly 的新手。 但我想这已经被问过好几次了。 也许它应该在常见问题解答中。

我的猜测是因为 .net 和 jvm 不仅仅是字节码，它们是一个具有自己的垃圾收集和类加载器和反射的虚拟机。 WebAssembly 实际上只是浏览器中独立的低级操作平台。 我认为您可以在 WebAssembly 中运行 JVM，但这不会给出您想要的结果。 它将简单地添加 WebAssembly 的启动时间和 JVM 的启动时间。 你会有两个不同的垃圾收集堆。 一个来自 JavaScript，另一个来自您的新 JVM。 我认为目前您使用 GWT 更好。

将 Web Assembly 视为 asm.js 的演变，而不是一种全新的技术更为准确。 它在 asm.js 上真正拥有的唯一功能是 64 位整数，大多数程序甚至不需要它。 这个有限的范围允许它相对容易地集成到现有的 JavaScript 引擎中。

Web Assembly 项目的一位资深人士可能会有更完整的答案，我同意这将是一个很好的常见问题解答项目，因为在 1.0 发布时这可能会经常出现。

Jvm 和 .Net 字节码专门用于它们的相关虚拟机，每个虚拟机都有自己的关注点和问题空间，它们试图解决与 Web 浏览器中运行的虚拟机不同的问题。 调整整个第二个虚拟机以在 Web 浏览器上运行对用户来说会很麻烦，而调整 JVM 和 .Net vm apis 以在现有虚拟机中运行在实现上会很麻烦，并且对用户来说不可避免地很麻烦，并且可能更容易出错/错误复杂性增加。 Web Assembly 被设计为更简单的 ISA，可以轻松地在浏览器中已有的现有 Javascript 虚拟机中运行，重点是优化传输时间和加载时间，现有字节码不能充分满足一组要求。

我确信我们在常见问题解答或基本原理文档中对此有所了解。 我们没有。 这将是一个很好的补充。

@kovalenko0如果我能提出我的意见。 JVM 和 .net 在 Web 上的表现不佳，因为它们会增加一个重要的攻击面，从而造成巨大的负担和膨胀。 如果将来他们可以在 wasm 沙箱中运行，那么这将增加一层可能减轻负担的保护。 Wasm 目前似乎专注于接近硬件的低级语言，希望它的沙箱攻击面小得多，并希望成为一般代码的好目标。 在低级语言方面还有一些其他非常重要的尝试，例如 NaCL，但在我看来失败了，因为它部署的熟本机代码太低级了，需要验证。 Wasm 希望只是一个更高级别的翻译层，它提供了更多的灵活性，并允许重定向到任何处理器，并且还为更一般的验证和将这些验证推论烘焙成优化代码开辟了道路。

@kovalenko0哦，让所有 Web 浏览器供应商同意捆绑 JVM 和 .net 也可能是一个太大的障碍（我预计是由于攻击面和膨胀等原因，但也可能是出于更琐碎的原因） ，所以 asm.js 与共同点一起工作。 Wasm 可能允许人们在 Web 上使用 JVM 或 .Net，即使 Web 浏览器供应商之间没有协议，也可以让人们对安全性和膨胀做出自己的判断。

我愿意通过结合这里的答案来补充常见问题解答，但是这个项目的贡献过程是什么？

确保您已加入社区组，然后向社区提交 PR
设计回购。

2017 年 1 月 27 日星期五晚上 7:56，Ryan Lamansky通知@github.com
写道：

我愿意通过结合答案来补充常见问题解答
在这里，但是这个项目的贡献过程是什么？

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/WebAssembly/design/issues/960#issuecomment-275744408 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/ALnq1BziU5qIZOBNq5fBYLfOjoeOkMIzks5rWj3SgaJpZM4LmzIH
.

贡献细节。 他们从“新公关”页面链接到😁

我最初计划在 LLVM 下方添加一个部分，但看到该部分是在 2015 年编写的，其中的某些部分已经过时。 例如...

我们相信，通过利用我们在 LLVM 方面的经验并根据我们的目标和要求设计 IR 和二进制编码，我们可以做得比适应为其他目的而设计的系统要好得多。

...鉴于当前的 WASM 二进制编码在浏览器预览中完美运行，这似乎过于谨慎。

我现在正在考虑将 LLVM 部分替换为关于现有字节码的更一般性的讨论（以 LLVM、Java 和 .NET 为例），措辞对 WebAssembly 团队采用的方法更有信心。

有异议吗？

@Kardax如何处理 LLVM 部分将取决于@dschuff / @sunfishcode。

@kardax也许最好不要添加任何东西，因为不同的设计有很多优点和缺点，并且仍然可以对 wasm 进行很多改进。 从您的角度来看，Asm.js 可能一直在“完美运行”，并且在某些方面比 wasm 具有更好的性能，因此它还有更多功能。 您可能想要探索解析/解码和编译时间和性能。

@wllang ...你在说什么？ 我从来没有说过 ASM.JS 比 WASM 有更好的性能。 我认为你完全误解了我写的内容。 我也强烈不同意 WASM 当前的 MVP 二进制编码有很多改进； 我会说按原样进行大约 98% 是好的，而我可以没有最后 2% 的生活。

@dschuff / @sunfishcode对 LLVM 位码的冗长讨论是否仍然相关？ 我认为专门的二进制编码的可行性已经得到彻底证明，因此我们可以通过在一个部分中解决 LLVM、Java 和 .NET 中间格式，一石激起千层浪。

@Kardax抱歉，无意暗示您“说 ASM.JS 的性能比 WASM 好”。 但是例如 Asm.js 有常量模块变量，这些变量可以被烘焙到编译代码中，这是 wasm 没有的东西，这是非常有用的，并且在 wasm 中获得类似的功能需要用户代码重写模块。

一个团队如何客观地评估 wasm 在 2% 之内的“好去处”的声明（无论这意味着什么）我们是否知道最好的性能是什么，最好的编码大小，最好的解码和编译速度等，最低的解码编译资源使用等？ 我们不想把它个人化，不是说某人最了解，甚至回应这样的说法也很困难，我们需要谈论可以根据技术价值进行评估的技术想法。

FAQ llvm 讨论对我来说很有价值，有很多优点，而且仍然非常相关，我个人仍在探索设计空间并发现这样的基本原理非常有用。

我们仍然没有真正高性能的解码和编译实现，我希望这些真的有助于最终确定设计决策，而且我看到设计可以朝许多不同的方向发展。 编码仍然具有非常不完整的定义最后使用信息（堆栈弹出给出了其中的一些信息），这是寄存器分配所需的，我希望实现溢出算法需要实时集，并且它们可能更多循环等。还有很多其他问题：部署管道，以及与 Web 浏览器对象的集成，这可能会以非常重要的方式翻转设计。

@Kardax是的，至少对于某些受众而言，LLVM IR 的讨论仍然相关。

顺便说一句，您提到了“可行性”和“完美工作”，但我建议在这个级别上，这些基本上是理所当然的。 很多东西都可以发挥作用； 问题是，为什么选择一个人而不是其他人？

有一段时间没有关于这个的公关告诉我没有什么兴趣。 我会关闭，如果有兴趣，请提交 PR 来修复。

我仍然认为这与 FAQ 相关。

打开#1061。

FWIW 微软的某人在 WebAssembly 上运行了一个 .NET 解释器作为实验： https :

https://github.com/appcypher/awesome-wasm-langs