在
有关WebAssembly的
上一篇文章中，我做了以下声明：
有些人将WebAssembly与Java小程序进行了比较。 从某种意义上说，它们是正确的，但另一方面，它们却被极大地误解了。 我会以某种方式写一篇有关差异的文章，但现在让我们谈一下相似之处。 从某种意义上说，WebAssembly是完成JVM意图的另一种方式：它是用于跨平台软件的普通虚拟机。
许多人对此主题表示了兴趣，因此让我们仔细看一下吧！ 在本文中，我们将WebAssembly与三种技术进行了比较：Flash，Java applet和PNaCL。 本文还重点介绍了在
Web上使用它的
方法 ，尽管我们之前曾探讨过使用脱机使用WebAssembly的选项。 但是稍后我们将讨论
这种比较。 最后，本文类似于吃西班牙小吃[许多不同成分的西班牙小吃-大约 人]，这是一堆小节。 在我看来，这有点短，但同时我正在尝试写博客，并且如果我继续扩展它，那将永远用光，所以很抱歉。
当您遇到以下WebAssembly描述时，我认为与Flash和Java小程序进行比较是很
自然的：
WebAssembly（简称Wasm）是用于堆叠虚拟机的二进制指令格式。 Wasm是作为可编译高级语言（例如C，C ++和Rust）的便携式版本而开发的，它使您可以在Internet上部署客户端和服务器应用程序。
这有点像过去的技术。 比较它们的连接方式并建议它们之间的细微差异是合乎逻辑的。 但是WebAssembly有很多不同之处。
被击败
WebAssembly与众不同的第一个原因是因为它成功了，而以前的技术却没有成功。 我的意思是特定意义上的胜利。 如果比较Flash应用程序的数量和WebAssembly应用程序的数量，Wasm可能会丢失。 WebAssembly的拥护者必须努力工作才能分发此平台。
当我谈论WebAssembly的胜利时，我的意思是它已经成为Web平台的一部分。 Flash，Java applet和PNaCL通过插件工作。 从某种意义上说，它们
不在网络生态系统之内。 它们从未包含在标准中，这非常重要。
从某种意义上说，这样的解释就足够了。 但是，仅仅指出一个事实并不意味着要解释其
原因 。 本文的其余部分将尝试弄清发生这种情况的原因：为什么WebAssembly成功了其他技术无法做到的事情。 在这里，
许多原因是相互关联的，但我试图将它们合理地分为不同的观点。
其他技术不适合该平台
你还记得吗？
还是？
这样呢
基于这些技术的applet实际上不是
Web应用程序 。 您有一个网页，其中切出一部分，小程序在此框架中工作。 您将失去其他Web技术的所有优势：既没有HTML，也没有CSS，也没有集成到Web的能力。 这些平台不会与浏览器中的其余平台交互。 好的，从
技术上讲，它们可以 ，但是实际上，这些技术的使用方式有所不同。
网络如何支持未与其集成的生态系统？ 这将永远不会发生。 用户最终坚决拒绝了它。 除了游戏之外，用户还
讨厌 Flash，而Java小程序又繁琐又慢。 这些技术并不根植于Web平台中。
另一方面，WebAssembly更接近JavaScript。 实际上，Wasm不会从您手中夺走部分屏幕。 他没有创造自己的小封闭世界。 现在使用JavaScript，并且
将来可以单独使用它与环境进行交互。 他只是...适合。
公司拥有的其他技术
Java属于Sun Microsystems，Flash属于Adobe。 为什么这很重要？
企业对互联网的影响是一个复杂的话题。
通常，网络在伪共识模型上运行。 另一方面，Java和Flash由各自的公司控制。 他们有很大的获利动机，而不是改善互联网。 这部分导致了上述情况：这些公司并不关心与平台其余部分的正确集成。 他们为什么需要它？ 对于企业来说，阻塞平台并完全放弃Internet的其余部分要好得多。 动机完全歪曲了。
WebAssembly是Mozilla，Google，Apple，Microsoft和其他公司的联合倡议。 它不会推广某人的特定平台，而是代表了公司和个人等广泛的利益相关者的共同利益。
WebAssembly遵循Web流程
公司隶属关系
还意味着这些技术从未遵循我们用于标准化网络的过程。 采用Web标准的过程已经很成熟，但是这些技术太大了，工作原理也有所不同。 相反，WebAssembly遵循Web技术采用的标准过程。
最初创建Asm.js的目的是证明我们可以使用Web进行出色的工作。 事实证明，它的执行质量很高，并展示了该技术的功能，尽管没有什么比这更好的了。
asm.js的主要优势在于它只是JavaScript代码：它与现有的生态系统完全兼容。 对于浏览器开发人员来说，“不要破坏互联网”是一个非常非常重要的规则。
WebAssembly是
asm.js的改进版本
asm.js 在围绕
asm.js找到共识之后
asm.js每个人都聚在一起使WebAssembly成为现实。 由于这不仅是JavaScript，因此他应该已经完成了在浏览器中实现的整个过程，并通过了它。 现在这是W3C规范，它
符合 Web标准，但并不与它们矛盾。
结果：其他技术过大且不稳定
Wasm成功的另一个原因：它很小。 Wasm采用其他Web技术的方法：在此基础上从小处着手，然后逐渐成长。 保持向后兼容。 过去的技术也没有遵循这一特定的社会惯例。 已为Flash和Java小程序加载了特定的运行时，因此不需要兼容性。 PNaCl建立在完全不稳定的LLVM IR代码之上。 他们将使它成为一个稳定的子集，但是如果LLVM更改，则会出现差异，这不是很好。
这些技术也太笨拙，无法实现稳定。 您能想象四个浏览器制造商完全定义JVM规范，然后永远接受这种语义吗？ 对于所有ActionScript，其本身是相似但不同的ECMAScript版本吗？ 对于所有LLVM-IR？
大型技术给情况带来了无法接受的风险。 这是一个全有或全无的交易，这是一个安全的“无”赌注。 另一方面，WebAssembly几乎不执行任何操作。 这主要是数学和JavaScript调用。 也就是说，在这里达成共识
要容易
得多 。
结论：其他技术需要一个完整的独立虚拟机
在本文中，我没有提到Dart，但它也适用于此。 句子“让我们将JVM放入每个浏览器中”是主要问题，因为该浏览器
已经具有JavaScript运行时。 即使一个运行时也很难维护，更不用说两个了。 以及如何整合它们？
另一方面，WebAssembly被设计为现有JavaScript虚拟机的一个小扩展。 虽然您
可以实现自己的WebAssembly虚拟机-这通常是通过WebAssembly脱机完成的，但是对于浏览器而言，维护成本要低得多。
其他技术太具体了。
WebAssembly基本上是独立于语言的。 Flash和Java小程序的主要目的是运行ActionScript和Java。 它们与它们的相对语义紧密相关。 甚至PNaCl都在某种程度上受此困扰：LLVM确实适用于类似C的语言，尽管程度不尽相同。
我们真的要为整个Internet选择一种语言吗？ 我们已经有了JavaScript。 有没有想过第三种语言？ 第四？ 从长远来看，采用独立方法会更好。
Wasm采取严格的安全措施
Java applet和Flash是真正的安全
噩梦 。 即使试图保护它们，实际上问题仍然不断出现。
另一方面，WebAssembly再次从JavaScript VM获得了好处：隔离其沙箱的所有努力也适用于Wasm。 在这里，缺少常规汇编程序的某些功能，这可能导致漏洞，例如堆栈破坏。 Wasm可以安全地使用内存，这非常重要！
另外，WebAssembly最初是在设计时考虑
验证的思想的 ：它是完全键入的，无需运行代码即可检查程序。 规范包括有关如何进行此类验证的说明。 这非常有用！
结论
关于这篇文章，我想说以下内容：它是从
开发人员的角度编写的。 但是开发人员很重要，因为他们控制着网络。 技术必须符合其目标-对于最终用户而言，这与便利同样重要。 在以后的文章中，我将尝试从用户的角度分析问题。 必须写很多东西！
总结一下：
- 其他技术未集成到Web平台中，这受到商业利益的阻碍。
- 其他技术需要太多：许多实施必须牺牲。
- Wasm具有很好的沙箱隔离和验证功能，而其他人则没有。