将Assemblyscript编译为Wasm，性能

Question

我看到已经有一个用于将TypeScript编译为WebAssembly（Wasm）here is the link的编译器。

我还从多个来源听说，由于JavaScript的动态性质和动态类型，将JS编译为Wasm是不可行的。

但是，TypeScript确实提供了JavaScript缺少的类型化变量。而且将来Wasm甚至可以与DOM交互/与其他Web API交互。

问题：

与用JavaScript编写Web应用程序相比，用TypeScript编写应用程序并将其编译为Wasm会带来任何性能优势吗？

Answer 1

现实的答案是：不。关于TypeScript有一些常见的误解。一是它不如JavaScript动态。事实并非如此，实际上它与JS一样动态，因为它包含了JavaScript的所有语义（包括所有疯狂的极端情况），并且其类型系统过于脆弱且不够完善，无法保证普通的脱机编译器可以用于静态优化。充其量，这些类型可以用作动态虚拟机可以首先对其进行优化的提示，因为他们知道它们可能最终是不正确的。

（此外，我还不知道TypeScript到Wasm的编译器。您可能正在考虑AssemblyScript，但是尽管它重用了TypeScript的语法，但其语义却大不相同。）

Answer 2

如果您可以将某些Javascript功能编译为Wasm，则可能运行速度更快。与其他动态语言相比，JavaScript的运行速度非常快，因为（大多数）浏览器将其编译为一个底层字节码，该字节码的解析速度非常快（甚至可以本地运行）。 Wasm的设计非常接近字节码，因此在最佳情况下，JS和“将类型编译为Wasm的JS子集”以相同的速度运行（如果两个编译器都做得很好）。但是：

1）JS源代码可能比Wasm代码大，因此从服务器加载它的时间更长（启动时间）

2）必须对JavaScript进行优化以使其运行速度如此之快，并且由于它不知道变量和属性的类型/生存期，因此需要一段时间才能使引擎找到最佳的编译方式，因此此优化过程需要时间。 （预热时间）。

这表示您不能出于各种原因将大多数JavaScript或TypeScript转换为Wasm（这就是为什么AssemblyScript是TS的子集）的原因

1）eval，with或仅仅是for(const el of [1, "seven", null])是JS中的性能杀手，但它们不可能编译为Wasm（因为它们是性能杀手）。

2）JavaScript具有垃圾回收。

Answer 3

您在问题中引用了AssemblyScript。汇编脚本是打字稿的极其严格的子集。不要将它与打字稿混淆，它是自我。最大的不同是Typescript包含了我们都知道并喜欢（讨厌）Javascript的所有动态属性。另一方面，AssemblyScript没有。

其中一些大的差异的例子是；在AssemblyScript中，不能有闭包。您也不能具有联合类型。