WASI 0.2.0 及其重要性

原文 ↗ Hacker News 讨论 ↗

WebAssembly 的新 WASI Preview 2 发布，被视为让 Wasm 成为浏览器之外实际可移植运行时的重要一步，这得益于其基于能力的系统接口，以及正在形成的组件模型/Canonical ABI，用于实现多语言互操作。评论者讨论这一做法究竟是过度复杂的“第二系统”，还是构建安全、serverless 风格工作负载和插件系统所必需的基础，并将其与 JVM/CLR、Java applet 和 NaCl 等更早的努力相对照。大家对真实世界用途（从 Figma 到 VS Code 扩展）和未来潜力（GUI API、Preview 3 中的 async 与 GC）抱有热情，同时也对缺失的部分感到沮丧，例如标准化图形、线程，以及为 C 等语言提供顺畅工具链的不足。

图形与 GUI API

  • 一些评论者希望为 WASI 制定一个标准的 framebuffer 风格 GUI API，让 WASM 应用能够在浏览器之外向屏幕绘制。
  • 另一些人认为 framebuffer 已经过时，更高层的 API 如 WebGPU 更好；反方观点是：WebGPU 目前还不够普及，而 WASM 的运行场景也不局限于浏览器。
  • 参与 WASI 的贡献者表示，图形功能并不是被厂商阻塞了；它只是一直没有得到贡献者的关注，而关注点主要在 serverless 和基础性组件上。
  • 社区对未来的 GUI/IO 设备提案很感兴趣，但目前还没有具体标准。

组件模型、Preview 2 与兼容性

  • WASI Preview 2 构建在 WebAssembly Component Model 之上，将“core WASM”与更高层 API 分离。
  • 现有 WASI 模块不能直接兼容；需要适配器，这被一些人视为混乱且具有“第二系统效应”。
  • 另一些人认为组件模型的目标是实现干净的互操作和规范化 ABI（不导出共享内存、基于句柄的资源），使不同语言和内存模型能够协同工作。
  • 组件模型可以在不使用 WASI 的情况下单独使用，并且正在走向标准化路径，尽管尚未完全正式化。

WASI 解决了什么问题

  • 有多种解释：仅靠 core WASM 无法进行 I/O；WASI 定义了一个基于能力的系统接口（文件、网络等），尤其面向非浏览器运行时。
  • 它常被比作“WASM 的 POSIX”，不过也有人指出 WASIX 更直接地瞄准 POSIX 语义。
  • 基于能力的安全模型（最小化、显式权限）被强调为关键设计目标。

使用场景与质疑

  • 质疑者认为，在约 10 年的 WASM 相关工作之后，他们看到的主要还是演示、复杂工具链和不明确的经济价值，尤其是与原生构建相比。
  • 另一些人列举了实际用途：浏览器应用（设计工具、游戏、视频、Flash 模拟）、嵌入式系统、多语言插件、VS Code 扩展以及游戏模组脚本。
  • 服务器端 WASM 被视为有前景但仍不成熟；性能和云厂商支持仍是悬而未决的问题。

与 JVM/CLR 和 Applet 的比较

  • 有人认为 WASI 是在重做 CLR、JVM 和更早期字节码方案中的想法；争论焦点在于，如果这个版本获得真正采用并且更开放，那么“重做”是否算坏事。
  • Applet 与 WASM 的比较中，评论者强调 WASM 暴露面更小、启动性能更好、面向多语言，以及有厂商联盟支持。

多语言、FFI 与未来特性

  • 社区强烈希望更容易的多语言 FFI；Preview 2 加上组件模型和 canonical ABI 被视为这一方向的基础。
  • 工具和框架（例如插件系统）正在出现，但在数据类型和易用性方面仍然受限。
  • 未来的新增功能，如 GC 和 async（Preview 3），被期待能让 WASM 成为更适合 JavaScript 和 Dart 等语言的运行时，并改善与编译为 WASM 的 JS 引擎的集成。