将网页浏览器作为 GUI，后端使用你偏好的语言

原文 ↗ Hacker News 讨论 ↗

将系统现有的网页浏览器作为桌面 GUI 层，而不是像 Electron 那样捆绑完整运行时，凭借 WebUI 项目展示出更小的二进制体积和语言无关的后端，这一点颇具吸引力。评论者同时也权衡了显著的代价：依赖当前安装的浏览器及其引擎版本、基于 DOM 的 UI 在性能和复杂性上的问题、原生观感不一致，以及浏览器发现、安全性和长期兼容性方面的棘手问题。许多人认为这种方式很适合简单、local-first 的应用，但对于复杂、高可靠性的软件则说服力不足。

项目思路与能力

  • WebUI 将本地浏览器作为 GUI 前端，后端可使用多种语言（C、C++、Zig、Python、Go 等）。
  • 它运行一个嵌入式 HTTP 服务器（civetweb），并通过 WebSockets 与浏览器通信。
  • 定位上比 Electron 更轻：约 200 KB 的库，不捆绑浏览器，适用于用户已安装的浏览器（Chrome、Edge、Firefox 等）。
  • 一些评论者喜欢利用现有浏览器而不是随程序一起分发运行时的想法。

对比：Electron、Tauri、平台 webview

  • Electron：捆绑 Chromium，提供完整的窗口控制和一致的运行环境，但二进制体积大、资源消耗高。对于使用前沿 Web API、需要保证兼容性的复杂功能型应用，它被视为必要选择。
  • Tauri：使用系统 webview 以获得更小的体积；在某些情况下也可使用其他运行时；提到的问题包括 Linux 上 WebKit 性能以及前后端之间的序列化开销。
  • WebUI：不同于 Tauri，它与独立浏览器通信，而不是 OS webview；不同于 Electron，它不控制窗口，因此自定义和原生集成受限。有些人认为它更适合较简单的工具和快速开发。

性能与 DOM / 布局争论

  • 一方认为浏览器提供了最强大的布局和渲染系统，而且对大多数应用来说，JS/DOM 已经“足够快”；性能问题主要归咎于开发者误用和过度抽象。
  • 另一方则称与原生或游戏引擎相比，DOM/布局“慢得像冰川”，并引用基准测试称中等规模的 DOM 负载就要花费数十毫秒，同时指出重排、重绘和动画限制的代价很高。
  • 关于基准测试是否有效（微基准 vs. “真实世界”）以及“足够快”到底意味着什么，双方有长期争论，但没有达成共识。

原生 GUI 与 Web GUI，以及用户体验

  • 有些人认为原生工具包（WinForms、Qt、JavaFX 等）可以快得多，也更简单，尤其适合传统桌面应用。
  • 另一些人强调浏览器的跨平台覆盖、响应式布局，以及桌面和移动端统一技术栈，接受非原生外观和更高开销作为权衡。
  • 还有几位指出，对企业来说，跨平台一致性和单一代码库往往比完美的原生观感更重要。

浏览器依赖、兼容性与长期可用性

  • 支持者认为，只要应用坚持使用通用功能，浏览器强大的向后兼容性使其在 5–10 年内仍然可行。
  • 怀疑者担心：
    • 依赖“系统里装了什么浏览器”，其引擎版本未知，且可能缺少功能。
    • 发现/启动浏览器以及需要 kiosk mode 参数的脆弱性。
    • 无法像 Electron 那样锁定固定的引擎版本。

安全与架构问题

  • 有人质疑安全模型（WebSocket + localhost），并将其与其他使用一次性令牌的项目作比较；风险画像也被拿来与过去基于 localhost 的问题（例如 Zoom）相提并论。
  • 该项目的主站曾短暂出现过期的 TLS 证书，一些人认为这对支撑应用的工具来说观感不佳。

其他讨论

  • 旁支争论包括：
    • GitHub 上 Zig 的语法高亮以及自定义 CSS 修复。
    • WebUI 标志与 Waterfox 标志的相似性，以及使用图标市场的风险。
    • 其他模式，例如“直接运行本地 webserver 然后打开 http://localhost:PORT”。
    • 与此前“浏览器即 GUI”尝试（CLOG、GNOGA）以及 Java applet/Flash 时代方法的比较。