\n\n文章指出WebAssembly的广泛采用有赖于组件模型最终确定。它在边缘计算等领域优于容器，但需流行语言上游支持。未来展望包括并发功能和惰性API，以实现“开箱即用”的开发体验。
译自：WebAssembly is now outperforming containers at the edge
作者：B. Cameron Gain
WebAssembly 的大规模采用尚未实现。
WebAssembly 的真正转折点——特别是它能够以毫秒级延迟将轻量级代码分发到任意数量的端点的能力——取决于组件模型的最终确定。
“WebAssembly 的真正转折点——特别是它能够以毫秒级延迟将轻量级代码分发到任意数量的端点的能力——取决于组件模型的最终确定。”
标准化组件模型将使 WebAssembly 能够在容器通常难以应对的领域取代它们，无论是否涉及 Kubernetes。Wasm 更适合边缘设备、无服务器环境和需要同时向无限数量的端点推送更新的事件驱动部署。
事实上，WebAssembly 已远超浏览器范畴。它通过在服务器、CDN 和后端服务中的可靠生产使用以及其广泛的适用性展现了其成熟度。
虽然核心 WebAssembly 故意设计成低级且难以直接使用，但最近的规范工作实现了更高级别的抽象。引用类型和接口类型允许组件暴露有意义的 API，而无需开发人员理解 WASM 内部结构，从而使该技术对工程师更易用。
在上周巴塞罗那 Wasm I/O 大会上题为“迈向组件模型 1.0”的演讲中，Fastly 的 Luke Wagner 描述了使所谓组件模型更易于采用的努力，包括推动原生浏览器实现和弥补一些剩余的功能差距。
“实现‘开箱即用’的开发者体验需要针对协同问题提供基于标准的解决方案……例如标准库如何执行 I/O，或者多个模块如何在运行时捆绑和链接。”
Wagner 表示，尽管调试和线程等技术改进很重要，但 Wasm 爆炸式采用的“更高优先级问题”是流行语言和框架中缺乏上游支持。
实现“开箱即用”的开发者体验需要针对协同问题提供基于标准的解决方案，例如标准库如何执行 I/O，或者多个模块如何在运行时捆绑和链接。Wagner 说，为解决此问题，该策略涉及两个层面：组件模型，它为计算和虚拟化提供基础解决方案；以及 WASI，它为各种类型的 I/O 定义了模块化标准 API。
Wagner 说：“我可能会有争议地声称，所有流行语言、工具、因素和框架都缺乏上游支持，以使 Wasm 能够在浏览器内外都能‘开箱即用’，这阻碍了 Wasm 的采用。”
Wagner 表示，WebAssembly Preview 2 已经剥离了组件模型层，而即将推出的 Preview 3 将其扩展为通过异步函数、字符串和 Future 来处理并发。此并发功能将成为完善组件模型的一个重要里程碑。
Wagner 表示，还计划从“即时”内存分配转向“惰性”API，通过反转控制流来减少堆碎片并提高性能。1.0 版的其他计划改进包括支持多值返回、添加错误上下文值，以及为使用垃圾回收内存的语言引入 GC API 选项。
Wagner 说：“通过 Preview 3，我们正在扩展 Wasm 模块，以解决许多并发问题。作为其中一部分，我们发现异步函数、字符串和 Future 是一等概念。”“因此，这个惰性 API 带来了许多好处。但是，我们如何在保持我刚才提到的所有重要稳定性的前提下更改 API 呢？”
Wagner 表示，与此同时，组件模型为开放问题提供了基于标准的解决方案，从而实现了“无处不在的上游支持，让宿主能够‘开箱即用’。” Wagner 说：“我们很快就会发布一个预览版，随后是协作线程和一个次要版本，为我们解决了一系列棘手的并发问题。”
为鼓励原生浏览器支持，Wagner 重点介绍了 JCO，这是一种将组件转译为 JavaScript 和核心 WebAssembly 的工具，目前已可在浏览器中运行。原生支持将通过避免 JS 粘合代码并允许 Wasm 直接调用浏览器代码来提供性能提升。
Wagner 最后呼吁社区通过围绕 guest 和 host API 构建共享工具来提交拉取请求，以帮助简化组件模型。该项目还需要更多文档贡献，以跟上提交的步伐。
Wagner 表示，还需要为上游化和跨语言工具提供贡献，并通过可选导入、回调、子类型等功能来弥补关键的表达性差距。
Wagner 说：“因此，我希望在座的各位在 Preview 3 发布后立即使用它，并使用 JCO 简化您的 Wasm Web 开发体验。”“如果您对我提到的众多 Bytecode Alliance 项目中的任何一个感兴趣，请贡献力量并在 Zulip 上的 Bytecode Alliance 与我们打招呼，您可以在 GitHub 仓库上阅读和讨论组件模型规范。”端 工智能
