[

当 WebAssembly 快得多时，为什么我们仍然使用 JavaScript？

](https://www.quora.com/Why-do-we-still-use-JavaScript-when-WebAssembly-is-much-faster)

快多了…例如，开始时的速度快了近 20%？

天哪，你肯定不敢相信！如果我使用 WebAssembly，我可能能够在 8 毫秒而不是 10 毫秒内看到响应！

需要注意的重要一点是，等待网页的大部分时间与JavaScript的速度无关。存在服务器延迟、在最小化网络请求方面糟糕的页面设计以及 DOM 渲染时间。JavaScript 很少是瓶颈。因此，为了更新上述示例，页面可能在 899 毫秒而不是 900 毫秒内呈现。以将代码移植到 C++ 的大量工作为代价，这些工作可以更好地用于实际优化页面，因为它实际上会有所帮助。

在某些用例中，WebAssembly 可以更快。它对于游戏很有用，无论如何，这些游戏通常已经是用 C++ 编写的。但在大多数情况下，WebAssembly 只是意味着“你可以编译 C++ 以在网页中使用”。

你知道吗？我用 C++ 开发了 GUI（图形用户界面，即像网页一样），用 C++ 开发 GUI 很糟糕。并不是说HTML+CSS+JavaScript是完美的，但它要好得多。而且更加灵活。而且调试起来要容易得多。还有更多的组件驱动。这个生态系统实际上是历史上任何语言中最大的生态系统。

其他人提到，你还不能从 WebAssembly 操作 DOM，但已经存在几个堆栈来处理这个桥。

而且有超过一百种语言可以编译成 JavaScript，所以如果 JavaScript 是一种如此糟糕的语言，我们是不是不会看到一种具有坚实现代工程原理的语言的崛起？哦，是的，我们是： 打字稿.

正如我上面提到的，大多数网站都很慢，不是因为 JavaScript，所以即使你可以直接从 WebAssembly 操作 DOM，并且你将代码移植到 C++，你甚至很难注意到速度差异。除了 DOM 和网络问题之外，可能下一个最常见的问题是正在使用的算法。通过将 JavaScript 转换为 C++ 来使您的代码快 10 倍是好的，但是仅仅通过稍微改变 JavaScript 中的算法来使其快 100 倍，就可以少得多的工作量以获得更好的结果。

那么，我们仍然使用 JavaScript 和编译为 JavaScript 的语言（如 TypeScript）的真正原因是什么？它更简单，更强大，足够快，生态系统无与伦比。除了游戏和专业库之外，我认为 WebAssembly 在可预见的未来不会有所作为。