加载失败
讨论围绕一篇主张把 WebAssembly 做为网页“first‑class”语言的文章展开，核心方案是将 WebAssembly Component Model（组件模型）与 WIT（接口描述）整合进浏览器以跳过 JS glue 并直接访问 DOM 与其它 Web API。评论引用了历史背景（asm.js、PNaCl、ActiveX）、现有工具链（Emscripten、wasm_bindgen）及 Bytecode Alliance 的实践，并重点争论字符串封送性能（如 Dodrio 实验中的开销）、WASM GC 的语义限制、并发模型、语言运行时兼容性与平台政治（例如 Apple 在标准推进中的影响）。多数人同意降低开发者体验（DX）门槛很重要，但对于应把复杂性放在哪里——浏览器内核、工具链、还是语言运行时——存在根本分歧，同时有人提出把庞大 Web API 拆分为可订阅子集并建立组件注册表的替代愿景。
支持者认为将 WebAssembly Component Model（组件模型）和 WIT（接口描述）纳入浏览器可以把 Web API 当作普通库导入，跳过大量手写或生成的 JS glue，从而显著降低跨语言通信成本并改善开发者体验。文章与评论引用了实验数据（如 Dodrio 中跳过 JS glue 可减少约 45% 的开销）和 Bytecode Alliance 的实践与工具（StarlingMonkey、ComponentizeJS、jco）来说明这条路径的可行性。他们还把组件模型视为在 WASM 之上建立统一接口层的方式，能够统一多语言互操作性，让语言编译输出“原生”融入浏览器生态，而不再把 WASM 仅当作边缘的计算加速手段。
反对者认为把组件模型整合进浏览器是“大炮打麻雀”：为了减少字符串封送或实现对 DOM 的高效访问而改动浏览器规范与实现，代价过高且易于过度工程。许多人主张应优先在工具链或宿主端（比如改进 JS 引擎的 fast-path 或工具如 Emscripten/EM_JS）解决字符串创建与绑定问题，因为这些现有工具已经能在不改内核的前提下缓解互操作和调试痛点。批评还指出组件模型会带来新的复杂性：生成大量 WIT/绑定文件、并发与资源借用模型复杂（例如 Go 示例生成的文件让人望而却步），风险是把原本显性的 glue 复杂度转嫁到库作者和语言团队上而不是简化上手路径。
大量评论把问题归结为“WASM cliff”——从零到可用的认知与操作成本太高，频繁的规范变动和早期工具链让入门门槛陡峭。具体表现包括：缺少 IDE 集成、难以一键生成/消费接口、调试支持不足、不能像写 HTML/CSS/JS 那样即时原型（记事本写 WAT 就无法直接预览），以及组件规范本身仍在演进导致 churn。许多支持者把目标定为尽可能把 WIT 隐藏在工具链后面，让大多数 web 开发者像用普通库那样自然地调用 Web API，而不是成为绑定工程师。
评论中反复提到 WASM 的垃圾回收（WASM GC）与各语言运行时之间存在语义和性能不匹配：目前的 WASM GC 不支持 interior pointers 等特性，使得像 Go、C# 这样的 GC 语言不得不捆绑自己的 runtime，带来体积与效率问题。组件模型又采用 borrow‑checking 风格的资源传递，这与 GC 语言的引用语义如何对接存在疑问（例如 DOM 引用如何保持存活、跨语言引用管理如何实现），社区历史上 stringref 提案因担心会“标准化 JavaScript 字符串语义”而未能推进也是背景因素。结论是，除非在 GC 特性与组件资源模型间找到兼容方案或语言团队愿意适配专门的 Wasm 运行时，否则跨语言互操作仍是重大工程挑战。
有人担心当网站越来越多地以 WASM 二进制形式发布时，可读性和可审计性会下降，闭源或混淆的二进制更易被用作恶意负载，浏览器可能被驱动去内置检测或云服务来应对这些问题，进而产生隐私与集中化的风险。另一个担忧是平台与政策因素，例如对 Apple 在标准推进中可能的阻挠的讨论（担心其保护 App Store 收入的动机会妨碍浏览器能力扩展）。对立观点则认为 WASM 的攻击面可能更小且更规则（默认无宿主权限、沙箱更小），而 JS 的 JIT 与复杂内建 API 本身就带来长期的安全成本，因此安全结论仍存在显著分歧。
有评论认为浏览器模型本质上是一个以 GC 管理对象图和动态类型 API 为中心的平台，JavaScript 与之天然契合，而 WebAssembly 的线性内存和静态抽象在语义上与 DOM 的对象语义存在阻抗匹配，这会在 FFI 边界引发性能与错误问题（历史上的 JNI、ctypes 等是参考教训）。支持者回应称两者并非互斥：组件模型与 WIT 可以作为中介层来描述类型并执行兼容性适配，而且在若干重度应用（Figma、游戏引擎、图形编辑器）中 WASM 已被证明不可或缺。总体争论集中在“是否通过中间层可以克服本质的不匹配”与“何处应该承担复杂性（浏览器、工具链或语言运行时）”上。
部分评论提出更激进的路线：与其把整个 DOM/API 原封不动暴露给 WASM，不如把庞大的 Web API 拆成小的可订阅子集（如信息展示、媒体、应用共享等），并建立 WebAssembly 组件注册表，让替代宿主或“轻量浏览器”只需实现相关子集即可运行应用。提议者认为这能改善安全边界、降低实现门槛并鼓励多样化宿主实现，把 WASM 定位为网络字节码与受限 UI 宿主（类似改良版 applet），同时可借助 WASI（系统接口）构建更一致的底层系统能力。反对者提醒这类重构需要长期协调、标准化与厂商政治的配合，短期内难以实现。
Component Model（WebAssembly Component Model）: 在 WebAssembly 之上定义高层组件和接口的规范，配合 WIT 描述接口和类型，目标是减少 JS glue、改善跨语言互操作并允许将 Web API 作为可导入的组件在宿主中运行。
WIT（WebAssembly Interface Types）: 一种接口描述语言（IDL），用于在组件之间定义类型、序列化与互操作约定，组件模型使用它来规范不同语言/宿主之间的调用边界。
stringref: 一个为 WebAssembly 设计的字符串表示提案，旨在高效地在 WASM 与宿主之间传递字符串；该提案因担心会无意中标准化 JavaScript 的 WTF‑16 字符串语义等争议未能推进。
WASM GC（WebAssembly GC proposal）: 为 WebAssembly 引入垃圾回收引用类型的提案，便于直接支持 GC 语言，但当前实现缺少诸如 interior pointers 的特性，影响某些语言运行时的性能或实现方式。
字符串封送（string marshalling）: 指在 WASM 的线性内存与宿主（JavaScript/DOM）之间转换字符串的过程（例如把 ArrayBuffer 的内容构造为 JS String），这个复制与编码步骤是当前 DOM 交互中的主要性能瓶颈之一。
Emscripten: 一个成熟的工具链，用于将 C/C++ 编译为 WebAssembly 并自动生成 JS glue，历史上用于解决浏览器互操作性和兼容性问题。
WASI（WebAssembly System Interface）: 为 WebAssembly 定义的受限系统级接口集合，用于在非浏览器宿主或未来扩展中提供文件、网络等系统调用的标准化抽象。