GPUI 与 egui 为何不适合复杂桌面应用
A Critique of GPUI
最近，越来越多的桌面 GUI 应用开始采用原生 Rust 框架，甚至连 Discord 这样的知名 Electron 应用也宣布用 GPUI 重写。然而，我认为 GPUI 和 egui 的状态模型对于复杂的桌面应用来说是一条死胡同。虽然它们都很出色，Zed 用起来确实流畅，我也在 Bevy 游戏中使用 egui 做调试界面，但它们不应成为原生桌面应用的默认选择。核心问题在于：任何 UI 架构最终都需要知道哪些数据变了、谁依赖它们，否则性能无法扩展。GPUI 的 notify 机制本质上类似 zone.js，只能粗略通知“可能发生了变化”，导致大量无效重绘；而 Elm 架构在小规模时清晰，但在复杂场景下维护成本极高。真正的解决方案是信号驱动的精确更新模型，但这需要放弃 GPUI 和 Elm 引以为傲的简洁 API。
每个 UI 框架内部都隐藏着某种增量化机制。
HN 评论区
93- x-complexity
这是一篇打着批评幌子的 zgui 广告。
从文章本身就能看出：
> 声明：我将 GPUI 当前的 Linux 渲染器移植到了 wgpu2，构建了下面使用的基准测试框架，并且我正在开发 zgui，这是一个基于信号的 Rust 框架，也出现在了图表中。
https://github.com/zortax/zgui
zgui 上个月才发布了 0.1.0 版本，开发历史仅 3 个月。而且这是它唯一的版本。
https://github.com/zed-industries/zed/tree/main/crates/gpui
https://crates.io/crates/gpui/versions
GPUI 的上一次发布是 0.2.2，距今已有一年。
框架的成熟度在选择应用移植目标时是一个不可避免的考量因素。
这是否意味着他们只能选择 10 年前的框架？当然不是，但他们也不应该去追逐只有 1 个月历史的项目。
凡事都有底线和上限，而底线就是“绝对不要选那些只有 1 个月历史且仅发布过 1 个公开版本的项目”。
- virtualritz
文章反复强调的核心论点是“它无法扩展（It does not scale）”。
对此我的回应是：“谁在乎？绝大多数应用的界面都不复杂”。
如果确实存在复杂界面，你也可以想些变通办法，比如文章里提到的 rerun 针对 egui 的做法。
举个例子：我最大的业余“灵感驱动”项目是一个已有 50 万行代码的混合 3D 建模应用。它使用的就是 egui。
就建模功能而言，它介于 Grasshopper 和 Houdini 之间，开箱即用约 200 个节点，外加任意数量的自定义节点。
这能让你对 UI 有个概念：节点图、参数编辑、控件覆盖层、操作器（gizmos）。很多节点都有自定义控件、渐变编辑器或曲线编辑器等。
这绝对不是一个简单的 UI。
但我从未花一秒担心过 egui 方案的性能问题。虽然 UI 渲染在我的每帧统计中有所体现，但完全可以忽略不计。
- jharsman
这个话题挺有意思，但这篇 AI 生成的文字读起来非常吃力，让我怀疑作者是否真的思考过这个问题。
如果你真的思考过，那就自己写出来。
- faangguyindia
那么，历史上最先进的 GUI 框架有哪些？它们为何优于 GPUI 或 egui？
过去哪家公司比 Microsoft 更需要 GUI？也许他们知道答案？或者是 Apple？
我不认为社交媒体应用的 GUI 复杂度足以推动该领域发展出如此先进的东西。
GUI 的复杂度和应用的复杂度是两码事。
文章中的论点听起来合理，但结论却跑偏了。
- pnyda
多拍代数效应（multi-shot algebraic effects）不是有帮助吗？假设我们将视图写成一个函数，作者希望的是下层栈帧能知道上层栈帧读取了哪些应用状态部分，这样当下层栈帧检测到应用状态的微小变化时，就能选择性地重绘上层栈帧返回的视图。支持多拍代数效应的语言允许这样做。我同意作者的观点，但正如我检查 zgui 所见，由于大量使用 Rust 宏，它的开发者体验简直是噩梦。我觉得这应该用另一种更适合该任务的语言来实现。