为什么我们连 Tauri 和 WebView 也跳过了

如果你最近关注过桌面应用框架,大概听说过 Tauri。它比 Electron 明显更好,对很多团队来说就是正确答案。在决定走原生路线之前,我们认真评估过它。

Tauri 的胜利是真的——但它只在「下载」这一层

Electron 把 Chromium 打包进去,所以每份安装包都背着约 150 MB 的浏览器。Tauri 什么都不打包:它用操作系统自带的 webview 渲染界面——Windows 上是 WebView2,macOS 上是 WKWebView,Linux 上是 WebKitGTK。

安装包从约 165 MB 降到约 12 MB。这是很大的进步,如果你唯一的指标是「下载要多久」,那讨论到此为止。

浏览器没有消失,只是换了个地方

有一件事不会体现在下载体积里:webview 依然是一个浏览器内核,而它依然要运行。

• 在 Windows 上,WebView2 就是 Chromium。启动应用时会拉起带独立内存的浏览器进程,和 Electron 一模一样——只不过来源从你的安装包变成了系统。
• 引擎初始化完成之前,第一帧画不出来。所以启动时间存在一个与你自己代码无关的下限。
• 渲染被交给了一个你无法控制、也无法调优的东西。不同平台带的引擎还不一样,「在我机器上渲染正常」是一类真实存在的 bug。

把三者放在一起对比:

Tauri 赢在下载体积,但并没有赢在「装完之后它要你付出多少」。

「原生」对 speedmark 意味着什么

speedmark 使用 egui——一个 Rust 的即时模式 GUI 库。它不向系统要 webview,而是自己绘制每一个控件,直接与操作系统的图形层对话。

这就消掉了启动下限和空闲内存税。没有引擎需要启动,所以窗口约 0.18 秒就出现;没有渲染进程,所以一个打开的编辑器约占 45 MB,而不是几百兆。

诚实的取舍

彻底走原生,代价是放弃了 webview 本来免费给你的东西:

• 没有 HTML/CSS 做布局,没有现成组件库——排版和绘制都得自己写。
• 文本整形、输入法和可访问性是 GUI 框架要解决的问题,不是浏览器的问题,需要实打实的投入。
• 相比 webview 方案,我们要维护更多平台相关的代码。

我们接受这些代价,是因为 speedmark 是一个小而专注的工具。如果我们要做的是带图表、表格和表单的仪表盘,我们大概会选 webview,并且会很满意。

工具要匹配任务。一个把「打开即用」当作核心承诺的编辑器,没资格在进程里塞一个浏览器。