Design: 会有 JS -> WASM 编译器吗？

浏览器仍然会有原生 JavaScript VM 和 wasm。 没有理由将 JS 编译为 wasm，因为您还必须包含整个 javascript vm。 生成的代码会比原生提供的 JS VM 大而慢。

MVP 后有一个任务，用于添加诸如从 wasm 代码添加对 GC 的访问等内容，以便可以为 wasm 实现脚本语言。

JS → wasm 只有在 wasm 支持 GC 时才真正有意义，而且很可能也支持 JIT 编译，这还有很长一段时间。 这基本上相当于在 wasm 中实现 JS 引擎！ 我最近提到了这一点， @BrendanEich指责我被 Horse_js 接管。

需要明确的是，wasm 的目标不是 _replace_ JavaScript，而是补充它。 因此，目前支持 JS → wasm 并不是真正的目标，但我们想要实现的功能将使之成为可能。 不过，我不确定从开发人员的角度来看它会那么有用。 您可能会缩小一些尺寸，但仅此而已。 从浏览器的角度来看，从纯粹的安全角度来看，在 wasm 中实现 JS 引擎可能会很有趣。

@jfbastien我打败了你 2 秒 ;)

但你的答案更好。 我对 wasm 中的 GC 和 JIT 感到兴奋。 我喜欢创建自己的语言并在网络上运行它们。

以及如何支持诸如 asm.js 或 TypeScript/ES7 之类的变体？ 这些
Javascript 的风格承诺某种程度的类型保证。

我想 JIT 的需求会少一些，但 GC 仍然非常多
这些语言需要。 会有一个{typed flavor JS} -> WASM make
这更可行吗？

女： http :

2015年6月在09:44 24日，蒂姆·卡斯韦尔[email protected]写道：

@jfbastien https://github.com/jfbastien你比我多 2 秒 :P

—
直接回复此邮件或在 GitHub 上查看
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456。

是的，asm.js -> wasm 翻译器是重中之重，Luke 已经做到了
在压缩机上工作，这可能是一个很好的起点。

2015 年 6 月 24 日星期三上午 1:59，Brendan Graetz通知@ github.com
写道：

以及如何支持诸如 asm.js 或 TypeScript/ES7 之类的变体？ 这些
Javascript 的风格承诺某种程度的类型保证。

我想 JIT 的需求会少一些，但 GC 仍然非常多
这些语言需要。 会有一个{typed flavor JS} -> WASM make
这更可行吗？

女： http :

2015年6月在09:44 24日，蒂姆·卡斯韦尔[email protected]写道：

@jfbastien https://github.com/jfbastien你比我多 2 秒 :P

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

—
直接回复此邮件或在 GitHub 上查看
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789。

我们已经与 TypeScript 团队讨论过这种可能性，他们也表现出了兴趣，但目前似乎在将类型化对象添加到 JS 方面取得了进展。

@bguiz ：JS 引擎是 wasm 引擎，它将继续支持不断发展的 JS 标准语言。 不用担心（我不确定您是否认为这可能会消失。在我可以预见的任何未来都不会）。 OTOH 正如其他人指出的那样，wasm 需要时间来发展 GC、JIT 支持和其他动态语言功能，成为 JS 的一流目标。 即使它确实发展了这些东西，我也怀疑 JS/wasm 引擎会放弃他们的 JS 语法和内置插件，转而支持下载的 JS-in-wasm 虚拟机。 我们会看到的！

/是

asm.js-to-WebAssembly 翻译器也将是我们计划添加到 Emscripten 的东西。

至于普通的JS，我想上面的问题其他人已经回答过了。

JS 的全部要点是易于编码并且可以做惊人的事情：dhteumeuleu 或 codepen.io/ge1doot，但是您可以看到源代码并且很容易破解。

“wasm”只是为谷歌、苹果和公司销售更多游戏和其他应用程序的一种方式。 唯一的“进化”是“无需安装”就可以更好地控制你，直接从大哥服务器......我很惊讶他们还不怕吃对方......

可以通过代码分析或代码注释将 ECMAScript 编译为 WebAssembly。 这听起来不像是 WebAssembly 团队的优先事项，但对于独立工作来说，这听起来确实是个好主意。

我刚刚开始尝试一种可能相关的玩具编程语言： https :

我会提醒人们不要在 wasm 上使用非常薄的包装纸，但一般来说。 作为一个例子，翻阅 Thinscript 代码，我看到有一个while语句被降低到loop { if (!condition) break; } ，这在几个 wasm 引擎上效率低于if (condition) loop { ...; br_if condition } 。

对我来说，使 wasm 不仅仅是重新加热的 JS 的原因在于可能有不同的哲学：因为 wasm 是编译器目标，编译器可以在将代码发送到客户端之前执行优化，因此我们可以使客户端 VM 更简单和快点。 但是，如果围绕 wasm 的瘦包装器变得流行，那么客户端实现最终将不得不变得更加庞大和复杂，以便进行尚未完成的优化。

是的我同意。 我最喜欢 WebAssembly 的一件事是它的简单性。 我计划在语言更完整后添加编译器优化并进行基准测试。 例如，我希望内联成为更大的胜利之一，而且我不希望 WebAssembly 为我做到这一点。 我还计划对机器代码目标进行试验，我将对这两个目标使用相同的优化。

听起来很酷！ 我有兴趣看看它会走向何方。

我想象 JS->WASM 对服务器比客户端更有吸引力。 作为我想到的架构的非常高级的概述......

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

在这个概念中，非常需要从 WASM 到LLVM IR的清晰映射以

个人想法，如有不妥请删帖！

跨环境兼容性是 JS 生态系统中的一个严重问题。 Babel 尝试通过转译为 ES 的一些更广泛采用的版本来解决这个问题，我想我们都可以说它非常成功。

不过这里仍然存在一个问题。 例如，如果您将 ES 2016 代码转换为 ES5 以实现兼容性，并且您的代码恰好在支持（部分或完整）ES 2016 的环境中运行，那么您将错过在您的环境中支持 ES 2016 的好处.

如果每个人都将他们的代码转换为 ES5，那么首先在环境中支持 ES 2016 有什么好处？

一个名为“babel-preset-env”的新项目试图通过按版本定位环境来解决这个问题。 它背后的想法是：(1) 您要求它针对浏览器的特定版本或“最新 X 版本”，(2) 它确定功能的最低公分母，以及 (3) 仅启用必要的转译。 这有帮助，但遗憾的是无法解决问题。

我们仍然面临主要供应商不作为并导致 Microsoft 多年来对 Internet Explorer 造成的相同问题的风险。 整个生态系统掌握在少数供应商手中，他们决定实施什么以及何时实施。 这不是免费的，也不是开放的。

唯一的解决办法是JavaScript的一个新编译的目标是高性能，需要一个比一个JS引擎少

JS -> WASM 通过代码混淆保护知识产权会很有趣，当涉及到客户服务器上的电子应用程序的本地安装时。 难以置信但事实如此，德国有许多小型机构几乎没有互联网连接，这需要在本地安装，但是将您的整个代码以明文形式提供给他们对于软件公司来说可能是可怕的。

@Simran-B Wasm 的设计原则是支持熟悉的文本格式。 值得注意的是，它具有用于快速分析的结构化控制流设计，并针对按堆栈顺序使用的一次性定义进行了优化，因此针对可读表达式进行了优化。 因此，它不是“代码混淆”目标，但开发人员可以在此基础上发出他们自己的“代码混淆”，但应该理解，这预计会在降低编码效率和降低性能方面产生成本。

大家好，我只是愤怒地发现了 WebAssembly，但是考虑到 JS -> wasm 编译器，我想象了一些类似 Angular2 的 Ahead-of-Time 编译的东西，jsut 方式更优化（我在考虑机器码而不是 javascript）......这会吗？有可能吗？ 这值得么？

编辑
我也在想，浏览器是否有可能向客户端发送一个标志，表明它支持 wasm，然后我们可以提供预编译的应用程序而不是 javascript 文件？

理查德

@Richard87您可以将 webassembly 视为独立于平台的指令集，具有自己的专用编码和调用约定。 没有什么说你不能描述一个 javascript 的子集，它很容易转换为在 webassembly 的世界中工作，但执行它可能很困难。 javascript 中的功能集和实现表面积永远在增长，并且使现有的库和框架适应该子集可能很困难，特别是考虑到当前在 webassembly 中缺乏垃圾收集，并且您基本上会失去现有 javascript 的好处代码。

随着在 webassembly 中添加垃圾收集原语，无需编写大型虚拟机即可进行转译的 javascript 子集将会扩大，但在我看来，与仅从更合适的虚拟机转译相比，它仍然不是最佳的语言，因为您在 javascript 中的开销只会稍微小一点，Web 应用程序（网络！）中的重要开销会扩大，并且您首先想从使用 javascript 中获得的好处仍然遥不可及，除了说它使用类似于“javascript”的东西（这实际上是 Unity 与 UnityScript 中的一条类似的船，除了他们对它进行了一些调整以更好地与他们的子系统和调用约定更好地集成，除了其他突发奇想之外）。

我认为对于我们中的一些正在寻找浏览器和 Webgl 的人来说，提高游戏速度是非常重要的。 我打算在 webgl 中引入商业质量的游戏，但当前的技术产生了太多帧跳过的垃圾。
使用 JS 游戏引擎的浏览器游戏几乎失败了，Unity 起飞了。 我认为 C++ => Wasm 对于像框架制造商这样的大型 Unity 来说是一个不应有的优势，他们可以将他们的代码交叉编译为 WASM。
但是那些使用 Three JS 或 Babylon 手工编写 JS 的人呢？ 没有 JS/Asm.js => Wasm 工具链将意味着 Js 中的大型应用程序将死，人们将使用 C++ 和代码生成后端来生成 Wasm。 更具体地说，在游戏等方面。
没有 JS => Wasm 后端对 JS 开发人员不公平。 EMCC 运行时也分配了一个 Big heap，因此速度很明显，但是由于编写此类代码的复杂性，编写好的 js 代码的 js 开发人员仍然无法获得如此高的性能。 应该有一些机制可以重用大多数东西，并且可以更早或随意调用 gc。 GC运行时跳帧导致Webgl跳帧是个大问题，需要解决。 应该有一些机制可以比代码生成器更好地手动调整 JS 代码。 就像手写的 Assembly 仍然产生更小和高度对齐的代码。 这在 web-assembly 中应该是可能的。

@metacritical C++ 可以编译为 WASM，因为很多人在这个过程中投入了大量的工作。 JavaScript 也可能发生同样的情况，但据我所知，目前没有人尝试这样做。 没有什么理由这样做：性能将保持不变。

您的引擎的问题是垃圾收集。 如果您构建一个使用线性内存和 WASM 代码的垃圾收集算法，这个问题就不会消失……最终您必须停止程序以查看哪些对象仍然活着并删除那些不是。 解决方案是不创建垃圾对象，从而避免 GC 运行的需要。 你不需要 WASM 来实现这一点，你需要重新设计你的引擎。

重用数组并产生低垃圾的超原始 Javascript 极难编写。 另外我认为普通 Js 不能编译为 WASM。 由于类型注释或类型分别可用，Asm.js 或 Typescript 更容易编译为 WASM。

@metacritical困难，但并非不可能。 即使在 C++ 引擎中，大部分代码也是围绕对象生命周期管理的。 尽管非常规，但您没有理由不能在 JavaScript 中做同样的事情。

普通 JS _可以_编译为 WASM，但编译器必须添加大量辅助代码以启用 JavaScript 的更高级别功能，如垃圾收集、反射、属性等。 基本上，您可以通过浏览器的内置 JS 引擎免费获得所有内容。 TypeScript 没有多大帮助。

相比之下，ASM.JS 很容易转换为 WASM。 ASM.JS 允许的 JS 特性的严格子集也 100% 被 WASM 覆盖。 如果有大量的代码是用 ASM.JS 编写的，这将是一个值得的努力，但据我所知，所有主要的 ASM.JS 文件都是由 C++ 源代码生成的，它们已经可以直接针对 WASM。

相比之下，ASM.JS 很容易转换为 WASM。

正确，实际上我们今天将 C++ 编译为 wasm 的主要方法是先将其编译为 asm.js，然后使用Binaryen 的 asm2wasm将该 asm.js 编译为

@kripken查看 asm.js 规范似乎很容易编写手写的 asm.js，这意味着 js 程序员不会丢失所有内容，我们仍然可以使用上述方法获得 WASM 二进制文件。

JS 的进化，即严格类型的语言，难道不能使它成为 JS -> WASM 的一个很好的候选者吗？
我认为 TC39 对类型化对象提出了建议。 可能还有更多其他功能可以使其成为可能。

@aruns07您允许人们使用的 JavaScript 功能

@Kardax @aruns07人们喜欢动态语言的便利。 我们偶尔需要强类型，而不是一直。

jfbastien 于 2015 年 6 月 24 日发表评论
JS → wasm 只有在 wasm 支持 GC 时才真正有意义，而且很可能也支持 JIT 编译，这还有很长一段时间。 这基本上相当于在 wasm 中实现 JS 引擎！

根据以下链接：
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
WebAssembly 共识和浏览器预览结束

现在，在您第一次回复后的 2 年，WebAssembly 现在已被主流 Web 浏览器支持。
所以不等同于在wasm中实现JS引擎。
js -> wasm 的优点不仅是 GC 支持，还有更小的代码量、更快的执行速度，特别是在 Hybrid 应用开发领域，比如 Ionic2 通常会产生 10MB 左右的 JS 文件，导致应用加载时间超过 5秒（每 2MB 解析 JS = 1 秒）

@jfbastien所以请发布您关于 JS -> wasm transpiler 的更新答案？

作为我硕士论文的一部分，我正在尝试编写一个从 JavaScript 子集到 WebAssembly 的转换器。 起初，它将仅限于 TypeScript，但未来可能会支持其他类型的变体，如 Flow。

但是，目标不是实现完整的 JavaScript 语言，因为在这种情况下，我将面临 JIT 实现今天面临的相同问题，因此，无法预期加速（更确切地说，我的实现会慢 100 倍！ ）。 它将是 SoundScript 定义的一个子集

我的目标更多的是允许将应用程序的特定部分编译为 WebAssembly，而无需开发人员离开他熟悉的开发环境或使用另一种编程语言。 因此，它更倾向于加速应用程序的性能关键部分，而不是作为接受任何现有 JavaScript 应用程序的通用转译器。

我很好奇我的发现会是什么，因为我看到了这种方法的利弊。 如果您有任何意见，请告诉我。

@Mohsen7s我的回答仍然准确：WebAssembly 的 MVP 版本不支持 GC 和 JIT 功能，这使得实现快速 JavaScript 虚拟机成为可能。 解释器是完全可能的，通过巧妙的技巧它可以非常好，但不如本地实现。

这是我们的“最小可行产品”方法所固有的：首先发布适用于某些用例的东西，然后添加功能以满足其他用例。 有关 MVP 和缺少“未来功能”的类似讨论，请参阅以下主题： https :

暂且不谈目前什么可以实施和什么不可以实施的技术讨论，我很惊讶 JS -> WASM 不是哲学和营销角度的第一目标 - 我看不出你会如何得到在这种情况下，开发商买入。 如果所有那些拥有能够在任何垂直市场工作的 JS 技能的前端/后端/全栈开发人员都想把时间花在学习 C++ 上，而 C++ 被用于更小的行业子集，那么他们早就这样做了所以 - 我知道，我作为一个人说话。 我不禁觉得整个讨论有点像回音室，那些为缺乏编译器辩护的人会发现他们的时间会更好地与煤面上的人交谈，询问他们真正想要什么。

@BossLevel

暂且不谈目前什么可以实施和什么不可以实施的技术讨论，我很惊讶 JS -> WASM 不是哲学和营销角度的第一目标 - 我看不出你会如何得到在这种情况下，开发商买入。 如果所有那些拥有能够在任何垂直市场工作的 JS 技能的前端/后端/全栈开发人员都想把时间花在学习 C++ 上，而 C++ 被用于更小的行业子集，那么他们早就这样做了所以 - 我知道，我作为一个人说话。

浏览器已经可以高效地运行 JavaScript。 浏览器无法有效地运行预期的用例。 最重要的是，WebAssembly 有非 Web 的愿望。

此讨论以及https://github.com/WebAssembly/design/issues/992#issuecomment -281735235 说明了不同人的各种目标。 没有错！ MVP 只需要优先考虑谁先得到服务。

我不禁觉得整个讨论有点像回音室，那些为缺乏编译器辩护的人会发现他们的时间会更好地与煤面上的人交谈，询问他们真正想要什么。

这就是组建 W3C 社区组的全部意义所在。 我们认为它成功了，正如我们从许多感兴趣的开发人员那里听到的那样。 有些人对 MVP 不感兴趣，但对未来的功能感兴趣。

@jfbastien

浏览器已经可以高效地运行 JavaScript。

哈，自 2008 年以来，我一直在尝试编写能够在普通手机上以不错的 FPS 运行的大型多人 HTML5 游戏，但我仍然没有做到！ 考虑到当我签订合同来支付账单时，我得到了非常丰厚的回报，我很确定我没有进步并不是因为我的代码质量。

这就是组建 W3C 社区组的全部意义所在

再说一遍——你知道有多少现实世界的开发者加入了社区组？ 这样做的开发人员通常是知识渊博的布道者等，是的，但对现实生活中的开发人员的痛苦感觉较少。

对不起，我真的不想贬低这个页面上/参与/在 W3C 上的任何人。 正如你所说，这是一个讨论，这是我在前线的观点。

很抱歉像狗担心骨头一样回到这里，但在离开时我想到了一个更好的方式来表达我的观点。 在您的下一个时事通讯/社区活动或任何获得反馈的方式中，将此问题提交给 Web 开发人员（您的客户）：

为了将基于浏览器的性能提升到一个新的水平，您需要学习另一种语言； 这是可以接受的吗？

因为这基本上是这个页面上的一些人已经（在我看来，有害地）回答的问题。

最后（我保证;-)） @jfbastien ，如果：

最重要的是，WebAssembly 有非 Web 的愿望。

为什么叫“WebAssembly”？

@BossLevel我想我知道你来自哪里。 我不能代表那些传福音的人，但我的理解是，不同的传教士已经接触过对 WebAssembly 感兴趣的传统“本地”开发人员。 从您的角度来看，这可能并不明显，但至少我可以指出 Unity 的兴趣是“认真”开发人员的标志。 这些人也以自己的名义在 github 上发帖，但从属关系并不总是很明显。 我没有资格为他们说话。

哈，自 2008 年以来，我一直在尝试编写能够在普通手机上以不错的 FPS 运行的大型多人 HTML5 游戏，但我仍然没有做到！ 考虑到当我签订合同来支付账单时，我得到了非常丰厚的回报，我很确定我没有进步并不是因为我的代码质量。

我并不是要暗示编写快速的 JavaScript 很容易。 我想说的是：WebAssembly 并没有让优化 JavaScript 变得更容易。 相反，它允许浏览器使用更适合生成可靠性能的格式。 它还允许 TC39 专注于改进 JavaScript 本身，而不仅仅是将 JavaScript 作为编译目标。

再说一遍——你知道有多少现实世界的开发者加入了社区组？ 这样做的开发人员通常是知识渊博的布道者等，是的，但对现实生活中的开发人员的痛苦感觉较少。

对不起，我真的不想贬低这个页面上/参与/在 W3C 上的任何人。 正如你所说，这是一个讨论，这是我在前线的观点。

你的观点确实有道理，我认为很明显，从你的立场来看，我说的话令人难以置信。 我们应该更好地传达这一点（或者嘿，也许我错了:wink:）。

为了将基于浏览器的性能提升到一个新的水平，您需要学习另一种语言； 这是可以接受的吗？

因为这基本上是这个页面上的一些人已经（在我看来，有害地）回答的问题。

我明白你的担忧，但我希望这不是事实。 再说一次，我可能是错的。 在我看来，WebAssembly 为这个平台带来了新的开发人员，这些开发人员过去在 Web 上有过糟糕的经历或听过恐怖故事。 反过来，它可以帮助想要使用“传统”代码（有些人称之为“遗留”）的 JavaScript 开发人员使用该代码：我们希望 WebAssembly 可以从 JavaScript 轻松使用。 要实现这一点，它需要像使用npm一样简单（这...并不总是那么容易！）。

由于我们在 Twitter、Hacker News、Reddit 和各种会议上看到的反馈，我有点相信这会发生。 再说一次，也许我错了，我在听回声室。 至少，我在会议上与具有 C++ 和 JavaScript 背景的人进行了非常有希望的讨论。

同时，TC39 也在真正尝试改进 JavaScript。 我相信它在最近几年，尤其是 ES6。

但您的观点仍然存在：也许开发人员希望精通 JavaScript以及更“WebAssembly 友好”的语言，例如 C++ 或 Rust。 我不知道事情会朝哪个方向发展。

为什么叫“WebAssembly”？

哈！ 这是一个很好的问题。 我有一个题为“WebAssembly：既不是 Web也不是程序集”的演讲。 我必须公开给它，这样我才能表达我对这个名字的感受:grin:

所以我会让你坚持那个。

我在这里读到两个愿望：

1. 用于快速加载时间的标准 JavaScript 的二进制表示。
2. 弥合本机编译的 C++ 和标准 JavaScript 之间的性能差距的东西。

第 2 项是许多公司正在进行的研究和大量投资的主题。 如果您查看过去 15 年对 JavaScript 引擎的性能测量，它也有效……差距越来越小。

据我所知，第 1 项没有被任何人处理。 它非常复杂，而且随着 JavaScript 的快速发展而变得越来越难。 WebAssembly 非常严格，也相对简单，而且还是花了很多年才开发出来的。

@jfbastien - 非常感谢您深思熟虑的回复:)

所以有几个说明性的观点，没有特别的顺序：

1）一个很好的例子，我看到了整个讨论以及我对你应该前进的方向的看法，在于 NodeJS - 一个 JS API/前端到 C++ 后端 - 你得到了易用性/熟悉等一方面，另一方面速度。
2) 坚持使用 Node，早在 2008 年我就开始了我自己的个人冒险之旅 ;-) 我最初同时着眼于后端的 PHP 和 Java（我在 IT 管理的黑暗面工作了十年后又回到了开发领域）和销售 ;-) !) 但很快就打折了，原因很简单，我只想学习一种语言，并且把那一种语言学好！ 我知道一个个人故事，但我怀疑我是唯一有这种感觉的开发人员，尤其是那些为自己工作的开发人员，而不是在学习语言时靠公司一毛钱。
3) 在提出下一点之前，我故意没有用谷歌搜索这些数字（实际上我不确定我是否可以）但我愿意打赌 ASM 的使用率很低。 我知道当我看到最初的演示时我非常兴奋，但在得知没有编译器后，我立即驳回了它。 要让一个拥有大量 API、库、资源、教程、框架等在线可用的全球最大开发社区 (JS) 的 Web 开发人员摆脱这一点，在我看来要求太多了，而且不向他们提供可能进行第一步的方法（即编译器），这会遗漏您的一个明显技巧。 我什至敢打赌，Shading langage (GLSL) 的发展比 ASM 增长更多，因为您可以 a) 将其直接编写到 Pixi.js 和 Three.js 等优秀框架中，并且 b) 使用它直接在ShaderToy等网站上。
4) 游戏行业/游戏一般。 我可以从这里的经验说：a) 我在过去 9 年里一直在编写（尚未发布！）游戏，b）我在TIGA （英国游戏开发商贸易协会）的董事会任职 2 年。 相信我，我认为想要迁移到 Web 的游戏开发者的数量可能是一方面可以计算的——游戏开发者已经进入了他们喜欢的行业，尽管如此，他们甚至还在拿薪水/长时间工作，所以这些不应该是 WA 的目标受众。 是的，他们的雇主一直在寻找新的媒体来移植他们的游戏，但我们不要自欺欺人，除了移动端（原生代码很遗憾地赢得了胜利，而这正是我希望 WASM 修复的），网络仍然是非常重要的在性能和货币化方面与 PC/控制台的关系不佳。
5) 相反，虽然卧室程序员/独立游戏的场景不像几年前那样达到顶峰，但仍有大量网络开发人员喜欢在业余时间制作网络游戏。 虽然我不想公然涉足政治，而且我绝不会打击 Unity 的人（我已经与他们中的许多人打过交道，这是一个很棒的产品），但我个人认为您应该关注利益多个小家伙，而不是一个大家伙（这既具有哲学意义又具有商业意义）。

我非常期待看到你的演讲@jfbastien :)

@RyanLamansky - 我认为你做出了合理的区分。 关于：

据我所知，第 1 项没有被任何人处理。 它非常复杂，而且随着 JavaScript 的快速发展而变得越来越难。

在完全个人的层面上，作为自 2008 年以来每天 8 小时编写 JS 的人，我非常希望看到 JS 的发展停止一段时间，让其他人赶上！ 我一直致力于为最低公分母开发的原则，即如果它没有 100% 的支持，它就不会发生（IE6/7/8/9 除外；-)）。 因此，当我们甚至没有在桌面和移动设备上获得对 ES5 的 100% 浏览器支持时，我们发现自己处于关注流行 ES6 模式和假设用例的荒谬位置。 正如它的市场份额所证明的那样，该语言显然按原样运行（尽管它被承认存在缺陷），那么作为一个开发人员社区，我们如何在接下来的几年里学习用我们拥有的而不是编写高效、最佳的代码再次用新的时髦代码重新发明轮子（对不起，我进入了咆哮的领域;-)）？

我想我可能是时候穿上外套了 ;-)

@RyanLamansky我遇到过这样的印象，即 WebAssembly 将成为您的包构建过程的新目标，突然间一切都会变得更快。 显然情况并非如此。 WebAssembly 有一个非常具体的目标用例，并且可能不会为典型的 Web 开发人员提供包含大量业务逻辑的大型 JS 代码库。

但是正如您所注意到的，对于更典型的面向业务的 Web 应用程序，基于 JS 的开发生命周期存在一些差距：
1) 大型 JS 包具有显着的解析开销，并且通常提供的混淆不足。
2) 标准 JS 代码缺少进行 JIT/Native 代码优化所需的类型注释（可能还有其他提示）。

这表明一个可能的解决方案是正确键入和注释的 JS 版本，它为开发人员提供更确定性和透明的优化路径，以及该语言版本的预解析二进制版本。

评论和文档说 WASM 在 JS 之外运行，并使用浏览器的相同 JS 引擎（优化）。 https://developer.mozilla.org/en-US/docs/WebAssembly

我真的不明白这个问题。

很抱歉问了一个愚蠢的问题并发表了一个愚蠢的评论：这个问题和 Webassembly 团队的评论是否意味着Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code?我只看到主观想法。 有人可以解释一下吗？ 如果 Webembly 比 Javascript 快，那为什么不提供一个转译器呢？ 如果 Javascript 是不可能的，那么为什么不使用 ES7/TS 代码呢？ 为什么这件事要保密？

@ganeshkbhat WASM的初始版本只不过是 asm.js 的紧凑二进制编码，它是 JavaScript 的一个非常严格的子集。 除非使用 64 位整数，否则它不会比 asm.js 运行得更快，因为这些必须在 asm.js 中模拟。

有人提议向 WASM 添加功能，使其在功能（垃圾收集、DOM 集成、线程）方面更接近 JavaScript，但没有计划添加完整的 JavaScript 功能集。 因此，JS->WASM 转译器很可能永远不会存在。 相反，将制作新的应用程序和库，旨在在 WASM 的限制范围内工作。 今天，这就是 C 和 C++，其中的语言限制与 WASM 和 asm.js 非常吻合。

没有秘密，也没有任何魔法。 Wasm “比 JavaScript 快”，因为它是一种更简单的语言，更接近硬件。 JavaScript 是一种复杂的语言，在执行期间必须做许多昂贵的事情。 通过 Wasm 而不是直接将其编译为本机代码，它不会神奇地变得更快。

@ganeshkbhat目前，无法在 asm.js/webassembly 中分配对象。 在 asm.js 和 webassembly 中，所有 JavaScript 操作都将使用一个大的 typedarray 来存储和加载那里的值。 创建 JavaScript 对象（例如var obj = {a: 1, b: 'test'} ）和数组（例如var a = []; ）在 webassembly 中是不可能的，因为尚不支持对象。 这是 Minimal Viable Product 的设计决策，旨在尽快在所有主要浏览器中获得 webassembly 支持。

在未来的版本中，计划为 webassembly 提供GC 支持。 我们（ LeaningTech.com 的开发人员）正在研究 webassembly 中对象支持的提案，但这需要一些时间才能成为所有主要浏览器的规范和实现。 在此之前，不可能将 JavaScript（以及 CoffeeScript、TypeScript 等）转换为 webassembly。 当提案被接受时，应该可以转译更大的 JavaScript 子集，但它不会支持当前可用的

当然。 请期待这里对 JS 的更好支持。 我绝对觉得它可以得到支持。 类型支持语言可能需要编写转译器。

从我读到的关于 webassembly 的内容来看，它主要针对 Web 浏览器，在该领域，使用 js -> webassembly 编译器听起来不太吸引人。 但我可以想象在非浏览器环境中运行 webassembly。 这并不完全正确，因为 in 也可以在 nodejs 中运行，但我看到它在 nodejs 环境中的真正潜力，例如vertx - polyglot 允许运行以任何语言编写的模块，可以编译为 webassembly。 我可以想象，完成这样的事情是非常困难的。 它将需要许多功能，例如 GC，甚至可能需要实现某种 VM，但没有什么是不可能的。 请记住，许多人也对 asm.js 持怀疑态度，今天就来看看它。

对于所有那些（像我一样）对编译 js -> webassembly 感到兴奋的人，将来可能会通过js -> c -> webassembly使用项目ts2c 转译器间接且非常颠簸。

@mauron85非浏览器和非 JavaScript 运行时环境绝对是设计的一个考虑因素，只是今天只有 JS API 存在。

就我而言，我一直在试验 .NET JIT 系统，除了时间之外没有看到任何真正的障碍，而且我相信还有其他人希望将 WASM 集成到他们最喜欢的平台中。 我确信几年后 WebAssembly 将会有高质量的非 JavaScript 运行时，唯一悬而未决的问题是它们将在多大程度上得到 WebAssembly 团队的正式认可。

IMO JavaScript -> WebAssembly编译能力的一个好处是，Javascript 库和工具的开发人员/维护人员可能能够以两种格式发布他们的 API：

1. 在 JS 中（就像现在一样），用户可以将其用于浏览器和节点
2. WASM 作为编译库可能更有效。

如果他们想在他们的 JS 库中释放 WASM 的性能优势，则无需用 C/C++ 重写他们现有的 JS 代码。
因此，库开发人员仍然可以使用 Javascript 进行开发和维护，并在 JS 和 WASM 中为两个不同的目标生成两个输出。

并且使用编译后的 WASM 版本库对用户来说肯定会更有效率，因为他们需要做的就是使用库中公开的 API，他们显然不会关心它是否是用 WASM 编写的。 但性能肯定会得到改善。

WASM 作为编译库可能更高效

为什么？ 为什么一团 javascript 会转译 Web 程序集（最坏的情况，包括该二进制文件中 javascript 引擎的大部分运行时；最好的情况，包括构建在未来内置 wasm GC 之上的层，无论如何都会产生自己的开销) 运行速度比在专门用于...运行 javascript 的 jit 上抛出的 javascript 还要快？

好的，您的意思是，开销越大，速度会越慢？

可能有什么地方我不太明白。 C/C++/Rust -> WebAssembly编译的东西如何真正有效，即使将来有JS -> WASM支持会导致开销？ 仅仅是因为 JS 是一种动态语言而 C、C++ 和 Rust 不是吗？ 还是因为 JS 本质上不是一种完全编译的语言，而这些其他语言是？

我想 JS 到 WASM 编译不太可能提高持续性能； 然而，由于二进制编码，它可能会改善代码大小和解析时间，这仍然很有用。

我认为我们可以为 JS 定义一个二进制编码，暂时忽略线性内存等。 这是简单且可填充的。

@kabirbaidhya现在 JS ->

JS -> WASM 的另一个主要障碍是几乎所有对象都是完全动态的。 WASM 本质上期望一切都是纯静态的，因此需要复杂的映射层、仿真和动态代码生成来接近标准的 JS 性能。 幸运的是，TypeScript 对此有所帮助，因此 TypeScript 的严格子集可能能够在某种程度上针对 WASM。 我知道至少有一个人试图建立这个。

C/C++ 与 WASM 的第一个版本配合得很好，因为 WASM 的限制与 C/C++ 旨在针对的本机硬件限制密切相关。

FWIW 有一个关于 V8 如何处理 JavaScript 算法的很棒的幻灯片： https ://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr 这只是_one_示例，其中现实比看起来要困难得多，实际上并没有多大意义，因为本机 VM 可以（并且可能会）做得更好、更快，因为它是真正的本机并且可以访问资源和 API 永远不会——而且（可能）最重要的是，多年的迭代。

这并不是说 JS/TypeScript 的 _subset_ 不能成功增殖，如ThinScript 、 TurboScript等。JS 程序员乍一看它们会很熟悉。

我仍然认为这些是很好的问题，并继续问。 我们都了解 WebAssembly 的用例和未来以及非目标，这一点至关重要。

4月6日2017年00:36，瑞安Lamansky [email protected]写道：

JS -> WASM 的另一个主要障碍是几乎所有对象
是完全动态的。 WASM 本质上期望一切都是纯粹的
静态的、复杂的映射层、仿真和动态代码生成
需要接近标准的 JS 性能。 幸运的是，
TypeScript 对此有所帮助，因此 TypeScript 的严格子集可能能够
在某种程度上以 WASM 为目标。 我知道至少有一个人试图
建立这个。

不幸的是，我怀疑 TypeScript 在这方面有帮助。 涵盖
JS 遗产，它的类型系统是如此深刻和根本不健全，以至于
没有有趣的“严格”子集。 例如，这样的子集将
需要排除任何 TS 的子类型概念，这将使它变得漂亮
在它的领域中非常无用。

有一些不错的研究论文，例如关于 SafeTypeScript，但不是
它们不仅受到更多限制，而且还需要大量
昂贵的额外运行时簿记和检查，违背了
讨论（并且实际上是一种与 JS/TS 不同的语言）。

也许我没有得到什么，但是WebAssembly的一个想法是直接加载AST以避免js的解析时间，对吧？

那么，如果我们有一个工具可以将 js 编译为这种 ast 格式并将其传递给浏览器，它会不会从避免解析时间中受益？

@agnivade，它是一个完全不同的，更低级语言的AST。

如果您要将 JS 离线编译为 Wasm，那么是的，您不需要在客户端解析（只需解码）。 同时，由于 JS 如此复杂，代码量会急剧增加，可能会增加 5 倍或更多，这是一个更高的成本。 （这甚至没有考虑到您可能还需要在 Wasm 中包含一个 JS VM 运行时系统的完整实现，这很容易就是几兆字节的代码。）

此外，如果没有源代码的表示，您将无法实现大多数动态优化，这些优化对于快速获得 JS 的任何地方都至关重要。 这些优化依赖于重新编译原始源代码并根据分析信息对其进行专门化。 已编译的 Wasm AST 无法启用该功能，您需要原始源程序的 AST。

@rossberg-chromium - 非常感谢。 这清除了很多！ 不过有一个疑问——

而且这甚至没有考虑到您可能还需要在 Wasm 中包含 JS VM 运行时系统的完整实现，这很容易就是几兆字节的代码

为什么需要 VM 运行时系统？ 浏览器本身不是 VM 运行时吗？ 我只希望代码采用 AST 格式，以便浏览器可以轻松开始执行它。 我知道净大小会增加，因为语言本身很复杂，我们无法实现动态优化。 但是为什么我们需要捆绑 VM 运行时本身，当我们有浏览器时呢？

@agnivade ，如果没有动态优化 JavaScript 会很慢，我的意思是 _really_ 慢，比如慢 100 倍，也许更糟。

我所说的“运行时”不是 DOM 之类的浏览器内容，而是 JS 语言的支持，即垃圾收集器、对象表示、原语和基础库等。这对 JavaScript 来说是非常巨大的，你会需要在 Wasm 中重新实现所有这些。

当然，您还需要一个 DOM 接口层。

好吧，我想我现在对事情有了更好的理解。 我以为

垃圾收集器、对象表示、原语和基础库等。

可以从浏览器本身使用。 我可以让浏览器加载 AST 并完成其通常的工作。 但现在我意识到一切都需要打包在 WASM 本身中。

不过，通用的脚本语言字节码会很有趣！ 一个编译目标，围绕有效传输和执行用动态类型、垃圾收集语言编写的程序而设计，流行程序（javascript、ruby、python、lua）的所有奇怪的边缘情况都包含在（某些情况下）特殊操作码和结构等中

@distransient ，所以你想要所有脚本语言的组合疯狂？ 我乐观地认为，到 2050 年，人类有可能收集工程资源以有效地指定和实施。:)

那些对使用 LLVM 将 TypeScript 编译为 WebAssembly 感兴趣的人。 看看这个触及项目。 https://github.com/MichaReiser/speedy.js
看来这个讨论永无止境……

@rossberg-chromium 我说这会“有趣”，不容易或漂亮😉

一个通用的脚本语言字节码会很有趣......

虽然 WASM 正在逐步发展以最终支持 Python 之类的东西，但如果我们同时从另一端解决问题，我们可以比 WASM 更快地为 Web 开发脚本语言提供一流的支持。

JavaScript 引擎公开其执行 JavaScript AST 的能力应该相对简单，并且它们接受的 AST 可以标准化（即使它们在内部立即转换为非标准的中间格式）。

我们可以简单地结合 AST 格式（如estree ）和序列化格式（如 JSON）来创建具有新扩展名的新文件格式。 如果浏览器支持脚本标签等格式，那么 TypeScript 和 CoffeeScript 之类的语言将编译为解析树，浏览器将从那里获取它。 转译语言不需要生成代码，也不再需要源映射，因为词汇信息将基于实际源。

一旦建立了基本支持，标准就可以逐步发展以满足中间的 WASM，基本上只是添加新的节点类型。 有一些简单的事情可以开始，比如显式的add和concat节点，或者可能添加新的数据类型，比如 DEC64。

随着 WASM 逐渐支持脚本语言，通过添加 GC 之类的东西，AST 执行将向下移动，扩展 JavaScript 语义以包含来自其他高级语言的功能，因此更广泛的脚本语言集可以编译为一种抽象的 JavaScript 。

2017 年 5 月 25 日 02:57，Carl Smith通知@github.com 写道：
>

有一些问题需要解决，但它会
JavaScript 引擎公开其内部支持相对简单
用于执行 JavaScript AST，它们接受的 AST 应该是
标准化（即使 AST 立即转换为非标准，
内部中间格式）。

仅适用于比您可能更广泛的“相对简单”的定义
记住...;)

相对于 WASM，它很简单。

@bguiz例如：

• 您无法将 JS 本地转换为 ASM，因为它具有不同的架构。
• 您不能从 ASM 操作 DOM，因为您无法在 CPU 底层访问它的资源。

谷歌 V8 引擎已经通过编译整个运行时任务，在执行之前直接将 JavaScript 编译为本地机器代码。

因此，完全没有必要从客户端获得替代的 WASM 管道。

另一方面，WASM 展示了 Mandelbrot 演示，然后它首先具有 Unity“Tanks”演示，但我非常怀疑使用 ASM->CPU（即使使用 SSE 双精度）绘制像素会更快比 WebGL->GPU，因为正如该社区所说，GPU 不在范围内。 所以呢？

@ivanherczeg哇！ 这个社区在哪里说 GPU 不符合规范？

@SephReed

由于 arm 和 x86 之间的自行车棚差异，我们已经感到紧张。 我认为添加另一组硬件目标会造成更大的压力：更多的操作要么由于仿真成本而不得不变慢，以便在所有目标上获得统一的语义，要么更多的操作必须具有未定义的行为以允许每个人快速运行。 我认为这使得此时（或以往）考虑 GPU 是无利可图的。

-Fil

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

C# 运行时被移植到 wasm 并且是完全替代 JS 的全功能原型。 所以这意味着将来你可以期待运行时出现来取代浏览器上的 JS 并用 Java、C# 甚至 C++ 编写客户端 Web 应用程序，并声明“代码将运行得更快接近本机” 、 “编译后的代码比 VM 快”或任何没有 JavaScript 帮助的东西。

请观看我想说的

引入 WebASM 是为了补充 JS 不完全接管，取代 First class 语言。

在不久的将来，您可以期待从本机编译的服务器交付的网页

https://github.com/ballercat/walt

@Steakeye非常好 :) 我要玩一出 - 非常感谢您的强调 :)

您可以使用 NectarJS 将 JS 编译为 WebAssembly。 演示： http :

有趣的是，NectarJS 演示使用 emscripten，您可以在 asm.js 输出中看到。 它似乎将 JS 静态编译成某种东西——可能是 C 或 LLVM IR——然后通过 emscripten 运行它。

wasm 输出也使用 emscripten（可以从检查二进制文件中看出），但它似乎使用旧版本，因为它发出 0xd wasm 二进制文件，这些二进制文件不能在现代虚拟机中运行。 它也只是向您发送 wasm，而不是 JS，因此无论如何它都无法运行。 在任何情况下，它很可能只是在做与 asm.js 相同的事情，只是运行 emscripten 并打开 wasm 输出的标志。

该演示对输入有 300 字节的限制，因此很难为它提供一个真实世界的程序来感受他们的分析有多强大，这就是像这样的静态方法的真正问题。 总的来说，关于这个主题的学术研究表明了怀疑态度。

他们为 Windows 编译的演示对我来说简直崩溃了🤕

我同意@kripken 的怀疑态度。 我相信任意 JS 不能合理地转换为 WebAssembly。 任何声称可以实现这一点的工具都可能正在处理 JS 语言的一些易处理的子集，或者放弃执行性能。

JS 是一种极其动态的语言。 不可预测的运行时操作可以显着地和全局地改变代码的语义。 这意味着 Ahead-Of-Time（或离线）编译器只能假设情况更糟，并生成可以处理所有可能情况的非常低效的通用代码。 以下面的 JS 代码为例：

var a = {prop1: 1};
func(a);

可以转换（在伪wasm中）到这个

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

现在，这与我们可以合理考虑的“编译”相去甚远，它更类似于展开解释器。 当然也可以运行编译为 Wasm 的 JS 解释器，但这几乎不会是性能上的胜利。

V8 和 Spidermonkey 等 JS 引擎可以通过实时编译来尽可能快地运行 JS 代码。 通过进行 JIT 编译，他们可以观察给定 JS 片段的真正预期语义，并为该特定情况生成快速代码，同时小心地检测环境中可能使当前假设无效的任何变化。

同意。 但是，我不介意使用 JavaScript 子集。 或者可能是一个类型化的变体，这可能会减少动态并允许生成更高效的代码。

BTW有关于“强模式”战线的消息吗？

@Simran-B，我们早就放弃了强模式，原因总结在这里。 结论是，在不失去与现有代码的互操作性的情况下收紧 JavaScript 语义几乎是不可能的。

出于同样的原因，我对设计 JavaScript 或 TypeScript 的“静态可编译”方言的想法也不抱太大希望——这将是一种无法运行现有代码的不同语言，所以没什么意义。

@Simran-B ：“不过，我不介意使用 JavaScript 子集。或者可能是类型化的变体”

在该领域有一些非常有趣的工作，例如 AssemblyScript，它是 TypeScript 的严格子集，可编译为 WebAssembly， https://github.com/AssemblyScript/assemblyscript

@rossberg ：“我对设计 JavaScript 或 TypeScript 的“静态可编译”方言的想法也不

我认为像 AssemblyScript 这样的东西的巨大潜力不在于运行现有代码（我同意你的看法，这通常是不可行的），但拥有一种友好和熟悉的语言是一件大事。

现在，如果您是 TypeScript 开发人员并且想要编写 WebAssembly，那么您需要使用 C++ 或 Rust。 两者都是很好的语言，但也有缺点。 对于具有这种背景的人来说，像 AssemblyScript 这样的东西可能是提高生产力的最快途径。

如果 AssemblyScript 可以编译为 JavaScript 和 Assembly，那将是非常理想的。 期待这些更新。

此外，将来，除非有人先这样做，否则我可能会尝试编写一个 TypeScript -> Assembly Script 转换器，它会遍历文件，提出需要提出的问题，然后进行转换。 希望它奏效！

@SephReed是的，它可以编译为 JavaScript，因为有一个WebAssembly -> asm.js 编译器，它应该适用于所有 WebAssembly 代码。

另请参阅“WebAssembly 可以填充吗？”

如果您的意思是“AssemblyScript 是否可以编译为惯用的JavaScript 代码？”，那么我不得不问，当 WebAssembly / asm.js 比惯用的 JavaScript 代码快得多时，您为什么要这样做？

虽然我认为您应该能够通过 TypeScript 编译器运行 AssemblyScript 代码。 但是，您需要牢记某些事情。

另请参阅 AssemblyScript 文档的这一部分。

先生们，请考虑WALT ，类似 JavaScript 的 WebAssembly 语言。

更新。 很抱歉发布尸检

我看到很多人认为这个“JS -> WASM”编译器是个好主意。

对于那些认为它没有用的人，例如：

不过，我不确定从开发人员的角度来看它会那么有用。 您可能会缩小一些尺寸，但仅此而已。 从浏览器的角度来看，从纯粹的安全角度来看，在 wasm 中实现 JS 引擎可能会很有趣。

拜托，这是我的具体示例，说明为什么它很重要，为什么它很有用，而不仅仅是您“缩小了一些尺寸，仅此而已”。 WebAssembly 附带的功能之一是：

<=XXX «砂盒环境» XXX=>

WebAssembly 不仅仅与性能有关。 你可能会看到Figma 团队的一篇关于插件的好文章。

制作插件系统非常具有挑战性。 您需要一些好的方法来运行自定义代码。 您需要一个单独的环境，一个安全的环境。

WebAssembly 为您提供了——一个纯粹的环境，没有像一些全局变量那样混乱。 在某种程度上，AssemblyScript 使它变得方便，您拥有与主应用程序环境几乎相同的 TypeScript 环境，这非常酷。

但这里的问题是，“几乎一样”：

我可以在我的安全环境中使用来自 NPM 的 JS 包吗？

不。

嗯，这个WALT项目是某种 AssemblyScript 替代品。 它几乎不像 JS，它是类型化的 js。 它更像是 TS 式的。 你不能用它编译/转换现有的 js 库。

我可以在我的安全环境中使用来自 NPM 的 TS 包吗？

不。

AssemblyScript 也是类似 TS 的语言。 如果它被类型完全覆盖，它可能会编译用 TS 编写的东西。 没有例外。 没有任何any的。 但是通常人们的配置不够严格，或者他们有几个@ts-ignore ，甚至更多时候， - 他们在 js 中编写包并在.d.ts文件中提供单独的类型 - 在所有这些情况下你将无法将这样的包编译为 WASM。

@JerryGreen优点，但在性能方面，我实际上认为这是一个巨大的误解，即除了节省几个字节之外没有显着的性能优势。 人们，包括基准测试，都非常关注运行时性能。 看看它运行 3D 游戏的速度有多快？

然而，现实世界的机会实际上在于启动性能，这对几乎所有网站大大加快，远远超出任何运行时的好处。 这就是为什么例如在文本内容上使用 gzip，例如 JavaScript，对 PLT 几乎没有实际影响——重要的是编译代码的大小。

讽刺的是，业界痴迷于 PLT（页面加载时间）和各种视觉完整标记，却没有人看到 WebAssembly 和这些向量之间的相关性？ 在大多数网站上，JavaScript 负责在这些关键事件之前花费的时间超过 30%。 事实上，与线性性能因素（即 JavaScript 启动时间和延迟）相比，页面大小和带宽对 PLT 的影响要小得多。

话虽如此，我还不清楚 JS -> WebAssembly 的可行性。

@JerryGreen Figma 的方法是非常具体的案例，我想对于大多数项目来说，iframe 或领域对于第三方 javascript 隔离来说已经足够了。 对于需要更多控制隔离且性能、大小和加载时间不那么重要的特殊情况，您始终可以将 QuickJS 或JavaScriptCore编译为 WebAssembly。

您还可以使用Web Workers ，并在删除您不希望不受信任代码访问的任何 API 的不受信任代码之前运行代码。 在这种情况下不需要 WASM @JerryGreen！

在真实的情况下，三个 js 中的帧率下降，我不确定 wasm 是否可以提供帮助，但至少在表面上看起来确实如此。

没有理由将 JS 编译为 wasm，因为您还必须包含整个 javascript vm。 生成的代码会比原生提供的 JS VM 大而慢。

我们不能通过Profile-Guided Optimization完成 JS VM 完成的所有单态化等工作吗？ 我们几乎会做与 JS 虚拟机在运行时所做的相同的事情，但要提前。

PGO 构建包含两遍：第一遍构建检测的二进制文件，然后第二遍使用从运行检测的二进制文件中收集的配置文件信息重新构建优化的二进制文件。

第一次运行将为我们提供所有类型信息（使用哪些类型参数调用哪些函数等），然后我们构建一个优化的二进制文件，其中包含调用函数的所有变体（+ 具有用于非配置代码的动态参数的泛型） . 我们不需要整个JS VM。

PGO 需要很好的测试覆盖您的程序。 这并不总是可能的。 但是您可以在 v8 中执行期间跟踪一些类型信息。 请参阅此文档： https ://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading =h.xgjl2srtytjt

我们已经与 TypeScript 团队讨论过这种可能性，他们也表现出了兴趣，但目前似乎在将类型化对象添加到 JS 方面取得了进展。

不需要类型

QuickJS 真的可以编译成 WASM 吗？

是的，例如 Figma 使用 QuickJS 作为他们的插件系统

它也在http://numcalc.com/ 中使用。