Zero-native：重新思考使用 Zig 和 WebView 的桌面应用开发

桌面应用开发的格局长期以来一直在网页技术的丰富性与原生二进制性能之间拉锯。多年来，Electron 通过捆绑完整的 Chromium 实例和 Node.js 运行时主导了这一领域，为开发者提供了巨大的灵活性，却以庞大的二进制体积和显著的内存消耗为代价。

于是出现了 zero-native，这是 Vercel Labs 的新项目，旨在弥合这一差距。通过利用 Zig 编程语言和系统原生 WebView，zero-native 承诺提供一种感觉像网页却性能如原生应用的开发体验。它针对现代桌面框架的“臃肿”，提供通往亚兆字节二进制和即时重建的路径。

核心架构：Zig + WebView

zero-native 的核心设计为轻量级外壳。它不捆绑沉重的浏览器引擎，而是默认使用 system WebView——即操作系统中已存在的浏览器引擎。这一架构选择使得生成的二进制保持极小，因为应用无需携带自己的渲染引擎。

关键技术优势

• Tiny Binaries and Low Memory（小体积二进制和低内存）: 通过利用 system WebView，zero-native 应用避免了捆绑运行时的开销，与 Electron 相比显著减小磁盘占用并降低内存使用。
• Flexible Web Engines（灵活的网页引擎）: 虽然 system WebView 是轻量级应用的默认选项，zero-native 仍允许开发者通过 CEF（Chromium Embedded Framework）捆绑 Chromium，以满足跨平台像素级渲染一致性的项目需求。
• Rapid Iteration（快速迭代）: 框架利用 Zig 的快速编译速度。开发者可以修改桥接命令或系统集成，并在几秒内看到结果，同时前端仍可受益于标准的网页热重载。
• Seamless C Integration（无缝 C 集成）: Zig 的一大亮点是能够直接调用 C 库。zero-native 继承了这一特性，使开发者能够包含 C 头文件并调用原生 SDK、音频编解码器或机器学习运行时，无需复杂的绑定生成器或“unsafe”包装器。

“桥接”与应用模型

为了让网页 UI 能够作为桌面应用运行，zero-native 实现了一个 Bridge。这使得在 WebView 中运行的 JavaScript 能直接与原生 Zig 代码通信。这种双向通信使网页开发者能够触发系统级操作——例如文件系统访问或硬件集成——这些在标准浏览器环境中通常是不可能的。

框架还提供内置的命令、对话框和系统托盘支持，确保“原生”体验从一开始就融入开发者的工作流。

社区争论：“原生”到底是什么？

和任何系统领域的新工具一样，zero-native 在开发者社区，尤其是 Hacker News 上，引发了热烈的争论。讨论的核心大多围绕“原生应用”的定义。

定义冲突

一些批评者认为使用 WebView——无论是系统提供还是捆绑的——都不算“原生”。在他们看来，原生应用是指使用操作系统原语（如 SwiftUI 或 WinForms）绘制 UI 的应用。

我不喜欢把依赖 WebView 的应用称为‘原生桌面应用’。在我看来，原生桌面应用意味着使用操作系统的原语和指令来绘制 UI。

与 Tauri 的比较

观察者注意到 zero-native 与 Tauri 之间惊人的相似性，后者同样使用系统 WebView 和基于 Rust 的后端。这引发了关于 Zig 与 Rust 权衡的讨论。zero-native 强调 Zig 的简洁性以及没有借用检查器以加速开发，但一些系统程序员将其视为劣势。

Tauri，但没有内存安全、资金、治理模型或人工维护者。

平台特定关注点

虽然跨平台基础的承诺很有吸引力，但一些用户指出“system WebView”是一个可变的概念。例如在 Linux 上，依赖 WebKitGTK 往往被视为相较于基于 Chromium 的替代方案体验不佳。

最后思考

zero-native 代表了一种更高效的桌面 Web UI 部署方式。它通过用轻量的 Zig 后端和系统提供的渲染器取代笨重的 Node.js/Chromium 捆绑，为希望获得网页灵活性却不想承担 Electron 资源开销的开发者提供了有吸引力的替代方案。尽管关于何为“原生”应用的哲学争论仍在继续，但技术目标十分明确：降低桌面软件的发布成本。