这是我在原帖下的一点评论。

不完全赞同作者的观点。理由如下：

1. 作者基本是完全站在一个纯前端开发者的角度来通篇讲述问题。而Wasm实际上是为全栈工程师打开了一道窗。让后端开发者也“有机会”利用自己已有的部分经验自己搞定前端了。这对于创业团队尤其重要，能少一个人就少一份支出；
2. 那场3个回合的大战，我整个过程第一时间在旁边目睹，真是酣畅淋漓。Rust+wasm的一个意义是让普通人不用太高的心智负担就能写出相对高性能的代码。一个JS程序员，写js代码的时候，心中默念一吨规则，我看这种js写起来也是很不爽的。这种基本靠程序员的自我修养写出来的中大型工程，从质量可靠性上来说，大概率是比不上语言的强制性规范的产出的；
3. 工具链自动化后，操作很简单。跟 webpack 等使用没什么区别，不知道你的“高度侵入性”，有什么特别的所指？
4. 看 wasm 当然不能只看 2020，如果统一看 2020 ~2025 这个阶段。wasm的标准会有不少实质性的改进，比如那个直接操作DOM的提案。这些IDL一旦做好，浏览器一旦支持。自然出现了一种可能性，在大部分场景下，是没有JS什么事的。这种可能性已经很明朗了；
5. 前端框架，引入 wasm，或完全用 wasm 重写，这种趋势已经开启了。并不是 js 党不喜欢或不愿意，这个趋势就会停止下来。背后自然有其驱动力存在的充分必要条件；
6. Rust社区已经有yew/seed这种前端框架项目，虽然现在也还在早期。但是随着wasm标准的完善，不排除首先会在性能上赶超现有框架。当大家闻到香味时，自然会有人参与完善这种前端框架及其生态。理论上来说，Rust+wasm写复杂应用，性能一定好于纯js写复杂应用。我说的理论上，理论一定需要现实条件的支撑，比如wasm规范的完善；
7. wasm 是难得的被4大厂同时积极鼎力支持的项目。正在以最快的速度完善规范，实现优化。对了，要说一句，wasm的规范是4大厂同时在做的，不是仅仅Mozilla一家。WebAssembly虽然由Mozilla提出，但是现在是整个browser工业界的共同追求。好不好自己判断吧；
8. 当然，wasm未来（大概率）的成功，并不代表js就会消亡（虽然我希望如此）。前端市场这块蛋糕太大，需求太多样性。一种方案，能占据其中一块蛋糕就可以了。没必要你死我活，喜欢用谁就用谁。比如，大量的前端培训市场出来的初级程序员，要他们去掌握 Rust+wasm 这一套方案，可能得花相当长的时间（不排除个别天才能很快掌握），效益还不一定好。但是甚少对于后端 Rust/C/C++/Go 社区的同学来讲，他们有机会去做一个复杂的前端App了；

总之，非常看好 wasm 在前端的发展。正如 4G 大大催生智能手机行业各种app的发展，5G 会更加拓宽无线互联的运行场景，wasm的到来和成熟，也将会将前端App的应用水平提升到一个新的层次，甚至超出我们的想象力。

后端我没说，是因为 wasm 在后端的潜力好像大家几乎没有什么异议。：D

在此感谢作者给的留言机会。

WASM 的目标是要重构前端生态，JS 只是其中一个过渡。但这么大野心的目标是不太可能实现的。更可能的情况是 WASM 的发展方向会走 JVM 的路，应该是在后端、服务端找到大场景。

WASM 的最大特点不是性能好，而是离硬件更近，性能好只是离硬件近的结果。通过WASI，WASM 有可能直接触达GPU 或者AI 加速的硬件。我们最近实现了用高通骁龙芯片对我们的WASM VM 进行AI 加速，这个 demo 在 Qcon 中也有展示。