OxideTerm 是一款我开发的免费开源的运维软件，具备 SSH 、SFTP 、端口转发、文件编辑、serial 、telnet 等功能。
GPUI 是 Zed 编辑器团队开源的 Rust 原生 UI 框架，直接用 Rust 构建桌面界面，不依赖浏览器 WebView 。最近在做 OxideTerm 的 GPUI 版本，顺便回头看了一下之前用 Tauri 的过程。我们最早用 Tauri 起步，就是因为它真的很适合快速做桌面端：前端生态成熟，Rust 后端也好用，包体积小，看起来也比 Electron 清爽很多。But at what cost ？
Tauri 一开始真的很香。包小、Rust 后端、前端生态成熟，看起来像是 Electron 的完美替代品。 但 OxideTerm 做到后面，我越来越觉得：它解决了 Electron 最显眼的问题，却把很多复杂度转移到了更难受的地方。
包体积是小了，WebView 还在；后端是 Rust 了，状态却被切成前后端两份；你以为自己在写原生应用，最后还是在给 IPC 、WebView 、Linux WebKitGTK 兜底。
前后端分离，双份事实容易相互污染
举几个实际例子：连接在后端，但是断连又要前端抓，重连、断线、任务取消、错误恢复，最后很多任务都要跨 IPC 来回同步，做久了发现容易两边都不完整。
很多东西放 Rust 后端很怪，因为它需要知道前面在干什么；放前端也很怪，因为它本质上又是连接、协议、系统资源。最后就变成前端一份状态，后端一份状态，中间一堆事件、命令、回调、序列化、反序列化。搞不好就是两份事实相互污染。说难听点，复杂到一定程度，可能反而不如 Electron 那种“大家都在一个 JS 世界里”的感觉。
WebView 还在，可能省不了太多内存
Tauri 包体积小是真的，启动也不错。但运行时还是 WebView 。UI 一复杂，多标签、多会话、终端输出、编辑器这些堆上来，内存并不会因为用了 Tauri 就突然消失（就例如 xterm.js)。Rust 后端确实香，高并发、协议、文件、网络这些都很舒服。问题是它和前端中间还隔着 IPC ，也会不如纯血 rust 性能好。
普通控制信号没什么问题。但终端输出日志流、输入事件这些一高频，JSON 通信就开始碍事。我们后来有些地方就是靠 WebSocket 绕开默认 IPC 。绕到最后就会想：那我当初为什么要这样？
（图为 tauri 版本空载内存，所有进程相加约 350 MB ）。
（ GPUI 版本 几乎只剩下三分之一，原生软件恐怖如斯）
Linux WebView 的坑
Windows 和 macOS 还好，Linux 上会被发行版、桌面环境、WebKitGTK 版本、输入法、字体、GPU 等轮流教育。这不完全是 Tauri 的锅，底层 WebView 差异就在那。但用户不会管这些，最后还是应用自己兜底。
所以我现在的感觉如果是设置面板、小工具、轻量客户端，Tauri 很合适。但如果是比较厚重的东西，要么索性就 Electron 追求快速开发+功能迭代，要不就不如尝试原生 App 了。
这也是我们现在在做 OxideTerm GPUI 版本的原因。GPUI 生态早，组件少，很多东西想要舒服要自己写，文档也没 Web 生态丰富，但至少它性能好得多，也相对统一一点。
最后介绍一下 OxideTerm
我们不只想做一个单纯的 SSH 客户端，而是想做一个运维工作台。平时干活经常不只是连一台机器敲命令，更多是在终端、文件、端口转发、远程桌面、临时 TCP / UDP 调试、多台机器会话之间来回切。
现在 GPUI 版在做这些：SSH 、Telnet 、Serial ，SFTP 和远程文件编辑，端口转发，Raw TCP / Raw UDP 调试，RDP / VNC ，多会话、多标签、连接管理。还在快速打磨，肯定有不少不成熟的地方。但方向很明确：少一点 WebView ，多一点真正围绕运维工作流的原生体验，让内存和应用性能表现好一些。
项目地址： https://github.com/AnalyseDeCircuit/OxideTerm
GPUI 预览版本下载（还在持续更新）： https://github.com/AnalyseDeCircuit/oxideterm/releases/tag/gpui-v2.0.0-gpui-preview.11
如果你觉得这个方向有意思，也欢迎顺手点个 Star 。开源项目真的很靠这个让更多人看见。
最后，也想听听大家做复杂桌面工具时最后是怎么选的：Tauri 、Electron 、GPUI 、Slint 、egui 、Qt 、Flutter 、Wails 、Dioxus ？
Select Language