误解了 WebAssembly 的重点

原文 ↗ Hacker News 讨论 ↗

WebAssembly 在 Web 技术栈中的角色存在争议：一些人认为它主要是让开发者用 JavaScript 之外的语言构建浏览器应用，另一些人则认为它真正的潜力在于成为一种低层、具沙盒隔离的字节码，用于插件、边缘计算以及浏览器之外的跨平台二进制。评论者讨论了它当前在浏览器中的局限，尤其是访问 DOM 仍需经过 JavaScript、工具链复杂以及运行时体积较大，同时也提到 Wasm GC 和组件模型等新特性，旨在改进互操作性和性能。与此同时，人们也在权衡不透明、已编译模块带来的安全性与能力，以及“查看源代码”透明性丧失之间的矛盾；后者曾让 Web 更容易学习和改造。

WebAssembly 的“用途”是什么

  • 一派观点认为，如今最大的好处是可以用 JavaScript/TypeScript 之外的语言编写 Web 应用。
  • 另一些人说，这早就可以通过编译到 JS 的方式实现（asm.js、ClojureScript、GWT 等），所以这本身只是渐进式改进。
  • 更“激动人心”的看法是，把 WASM 看作一种通用、安全、可移植的计算/沙盒层：插件、边缘计算、IoT、安全的原生依赖等。

Web 上的 WASM 与 JavaScript

  • 许多开发者希望 WASM 取代 JS，这样他们就能在客户端和服务端都使用自己偏好的语言。
  • 也有人认为 JS 已经足够好，甚至很强，问题更多出在生态/工具链，而不是核心语言。
  • 一个反复出现的实际模式是：让 JS 继续做“脚手架”或胶水，把性能关键路径或重量级库卸载到 WASM。

DOM、浏览器 API 与工具链

  • 在浏览器中，WASM 不能直接使用 DOM 或大多数 Web API；它必须通过 JS“宿主函数”作为桥接。
  • 借助 reference types 和 Wasm GC，传递不透明的宿主引用（例如 DOM 节点）会变得更容易、更高效，但仍然需要胶水代码。
  • WebAssembly Component Model 和 WebAssembly Interface Types（WIT）正在开发中，目的是标准化更丰富的互操作，但进展缓慢且复杂。
  • 有人抱怨工具链过重、语言运行时过大，以及在代码拆分和启动时间优化等方面做事很困难。

不透明性、“查看源代码”与可访问性

  • 一个强烈担忧是，WASM 会让 Web 变得不透明：编译后的二进制比 HTML/JS 更难理解，这会削弱“查看源代码”的文化和随手学习的可能性。
  • 也有人反驳说，压缩后的 JS 本来就已经很不透明，而更好的工具也可以像处理 WASM 源码一样把它暴露出来。
  • 以 Canvas 为中心的 WASM 应用可能会带来较差的可访问性（屏幕阅读器、文本选择、国际化文字排版），除非额外投入并使用相关库。

与其他字节码的比较以及新颖性

  • 有人说 WASM“不过是另一个字节码”，就像 JVM/CLR 一样，不值得这么多炒作。
  • 另一些人强调它的不同之处：更低层、语言无关、形式化规范并经过机器验证、强沙盒、最小的环境能力。

采用情况、使用场景与质疑

  • 被提到的例子包括：复杂 Web 应用（设计工具、类地球浏览器、Unity 游戏、C#/Blazor）已经在有效使用 WASM。
  • 怀疑者认为，近十年过去了，WASM 在 Web 上仍然没有一个清晰、占主导地位的“杀手级应用”（没有直接 DOM、线程支持别扭、需要很多胶水），并质疑是否真的有必要或明智去追求一个通用计算层。