从 Tauri 到原生渲染：为什么我开始关注 Makepad

前言先郑重声明一下这篇不是Makepad 入门教程也不是“看完立刻上生产”的安利文。它更像是我最近重新看了一圈 Rust 客户端生态之后做的一次技术选型笔记。如果你现在刚好有下面这几种想法这篇文章可能会对你有帮助想用 Rust 做桌面应用但不想只停留在命令行工具。觉得 Tauri 很香但又隐约觉得“WebView 前端壳”不是唯一答案。想知道 Makepad 到底值不值得关注而不是只看几张截图就热血上头。这篇文章只回答一个问题为什么是 Rust GUI以及为什么我觉得 Makepad 值得现在开始关注。1. 为什么 2026 年了我还在看 Rust GUI很多人第一次听到 “Rust GUI”第一反应其实挺统一的这东西成熟吗有必要吗我直接 Tauri 不就完了这个问题一点都不过分。因为过去几年Rust 在客户端领域最容易落地的路线确实是Rust 做后端能力前端继续写 HTML / CSS / JavaScript再通过 WebView 打包。这条路线的代表就是 Tauri。从 Tauri 官方文档的当前定义看它本身就是一个面向桌面和移动端的跨平台框架前端技术栈基本不设限同时它依赖各平台自己的 WebView 运行界面比如 Windows 用 WebView2macOS 用WKWebViewLinux 用webkit2gtk。这也是它为什么能保持较小体积、上手又快的原因之一。来源Tauri 官方文档https://v2.tauri.app/start/https://v2.tauri.app/reference/webview-versions/说白了Tauri 解决的是一个非常现实的问题我想快速做出一个像样的跨平台客户端而且我已经有现成的前端经验。这个场景下Tauri 几乎没有什么理由不进候选名单。2. Tauri 很强但它解决的不是全部问题我以前看桌面方案的时候默认动作就是先看能不能用 Web 技术复用现有团队能力。如果能优先 Tauri。如果要性能、复杂渲染、图形交互再考虑别的。这个决策没毛病。问题在于你做得越深就越容易发现“能做”和“适合做”不是一回事。举个例子。如果你做的是设置面板笔记工具表单型业务客户端简单的数据管理后台那 Tauri 的体验大概率是非常好的。你甚至可以把它理解成#[tauri::command]fngreet(name:str)-String{format!(Hello, {name}!)}前端继续写页面Rust 负责本地能力和性能敏感逻辑。这个分工非常清楚。但如果你想做的是下面这些东西味道就开始变了对动画流畅度更敏感的界面强交互、强绘制的工具类应用希望 UI 心智模型尽量统一在 Rust 里不想一直在 “前端一套状态 Rust 一套状态” 之间来回切这时候你会发现WebView 路线虽然能跑但它天然会把你拉回 Web 的世界里。不是说这条路不好而是它的核心优势和核心边界其实是同一个东西它太擅长复用 Web 了。3. Rust GUI 这件事真正让人纠结的点是什么我觉得 Rust GUI 最难的地方不是“有没有库”而是“你到底想要哪一种 UI 编程模型”。这是很多人一开始没想清楚的。3.1 WebView 路线工程效率很高但本质还是前端应用这条路的优点非常明确上手快生态成熟前端人力可复用跨平台经验相对稳定但它的代价也很明确UI 主战场仍然是 HTML / CSS / JavaScript你依然要接受浏览器那一套渲染和调试心智一旦交互复杂状态边界会重新变得微妙所以 Tauri 更像是“Rust 能力注入到前端客户端里”而不是“我在 Rust 里获得了一套真正舒服的客户端 UI 体系。”3.2 immediate mode 路线写起来顺但不一定适合所有产品形态另一个很常见的代表是egui。根据 egui 官方仓库当前描述它是一个 “简单、快速、高可移植” 的 Rust immediate mode GUI能跑在 web 和 native 上。官方也明确强调了它的定位易用、好集成、简单但不以“最强大”或“原生观感”作为第一目标。来源egui 官方仓库https://github.com/emilk/egui它的典型心智大概是这样ifui.button(保存).clicked(){self.save();}这种写法的好处非常直接逻辑顺没有那么多 callback 绕来绕去对 Rust 的所有权和状态组织更友好但它也有很明显的 trade-off。如果你要做的不是 debug 面板、内部工具、配置页而是更强调界面结构、视觉表达、长期组件化的产品immediate mode 不一定是最顺手的那一条路。所以问题就来了有没有一种 Rust GUI 路线既不是 WebView 包壳也不完全停在 immediate mode 的舒适区里这时候 Makepad 才真正进入我的视线。4. 为什么我开始认真看 Makepad我这次重新看 Makepad不是因为它“新”而是因为它提供了一种很不一样的判断方向。从 Makepad 当前官方站点和 GitHub 仓库的公开定位看它把自己定义成面向 native 和 web 的跨平台 Rust UI runtimeRust-first 的框架带有脚本化 UI DSL强调高性能 UI runtime、live editable design language 和快速迭代来源Makepad 官方站点与官方仓库https://makepad.nl/https://github.com/makepad/makepad这几个点单独看都不新鲜但放在一起就有意思了。4.1 它不是“Rust 调前端”而是“Rust 自己就是 UI 主场”这是我最在意的一点。很多框架说自己支持 Rust实际意思是Rust 负责后端UI 还是前端Rust 是能力层不是界面层Makepad 不太一样。它想做的是让 UI 本身就留在 Rust 的世界里。这件事的价值不只是在“语法统一”而在于你处理这些问题时不必每次都跨栈状态放哪数据怎么流组件怎么拆本地能力怎么接渲染和交互怎么协调如果这条路真的成熟它对 Rust 开发者的吸引力会非常强。4.2 它更在乎渲染和交互而不是只在乎“把页面显示出来”Makepad 官方仓库当前公开列出的能力里已经明确把 GPU 加速 2D / 3D 渲染、地图、3D 示例、可迭代的 Studio 工具链放进核心叙事里。这意味着它的关注点不只是“我能画个按钮”而是我能不能把交互体验做顺我能不能把绘制能力做深我能不能让这套 UI runtime 支撑更复杂的客户端形态这个方向和 Tauri 的出发点明显不一样。Tauri 更像“交付效率优先”。Makepad 更像“客户端 UI 能力本身值得被认真构建”。两者没有谁天然碾压谁它们解决的是两类问题。4.3 它的 DSL 和 live design让我觉得它不只是一个控件库Makepad 当前对外很强调它的 UI DSL 和 live-editable 设计语言官网现在把这套 DSL 叫作Splash并且把“可生成、可检查、可迭代”放在很靠前的位置。这一点我会先保守看待不会直接吹成“下一代 UI 编程范式”。但至少它说明了一件事Makepad 想解决的不是“Rust 里缺几个按钮和列表”而是想重新组织一套 UI 开发工作流。这件事如果做成意义会比“又一个 GUI 库”大很多。5. 但我要泼点冷水Makepad 现在并不是万能答案如果你读到这里已经准备cargo add makepad我建议先停一下。因为这篇文章的重点不是“Makepad 已经赢了”而是它值得关注但你最好带着预期管理去看。我当前的判断是Makepad 至少有三个现实问题要正视。5.1 生态心智还没有像 Tauri 那么稳Tauri 的优势之一就是你几乎不用重新学习“什么是客户端 UI”。你会 React、Vue、Svelte基本就能接上。Makepad 不是这种路线。它要求你接受一套新的 UI 组织方式这本身就有学习成本。5.2 社区体量、资料密度、现成案例暂时都不是它的强项这不是批评而是阶段现实。你做技术选型时不能只看“理念是否先进”还得看遇到坑能不能搜到答案有没有足够多的项目参考团队里第二个人接手时会不会一脸问号这些问题Makepad 今天大概率还没有 Tauri 那么轻松。5.3 你得先确认自己到底是不是在找“原生 UI 路线”很多项目其实并不需要一条更原生、更底层的 UI 路线。比如一个内部工具平台、一个运营后台客户端、一个简单知识管理工具如果你的第一目标是尽快上线、快速迭代、招聘容易、团队协作顺畅那 Tauri 依旧很可能是更优解。Makepad 不是来替代所有人而是更适合下面这类需求想用 Rust 把 UI 和业务尽量放在一套语言里对渲染、动画、交互手感更敏感愿意为长期能力储备接受前期摸索成本6. 如果让我今天做选择我会怎么选这一段我尽量说得直白一点。6.1 要快要稳要团队马上能干活选Tauri。原因不是它“更高级”而是它的工程路径最短。你可以继续用熟悉的前端方案再让 Rust 去接系统能力、性能逻辑、文件处理、本地数据库这些部分。6.2 要一个写起来顺手、逻辑流畅的 Rust GUI先看egui。尤其是工具型应用、调试面板、可视化辅助界面它会让你非常快地进入状态。6.3 想认真观察 Rust 原生 UI 的下一条路那就看Makepad。注意我这里用的是“看”不是“无脑上”。但如果你问我在 Rust GUI 这个方向上哪一个项目让我觉得最值得持续追踪我现在会投 Makepad 一票。不是因为它已经最成熟而是因为它试图回答的问题更大Rust 能不能不靠前端壳真正长出一套像样的现代客户端 UI 体系这个问题一旦答出来价值会很高。7. 我为什么会继续写这个系列因为我发现中文语境里关于 Makepad 的内容很多要么太短要么太碎要么直接跳进 API 细节。但对大多数人来说真正重要的问题其实是前两个它到底解决什么问题它和我已知的那几条路有什么本质区别所以这个系列我会按下面的顺序往下写为什么是 Rust GUI为什么关注 MakepadMakepad 和 egui、Dioxus、Tauri 到底怎么选从零跑起第一个 Makepad 项目Makepad 的 UI 代码到底该怎么读先把判断框架搭起来再进具体代码会顺很多。总结最后收个尾。如果你只是想找一条最快落地的跨平台客户端路线Tauri 依然非常强。但如果你在意的不是“把前端打包成桌面应用”而是“Rust 自己能不能长出真正像样的客户端 UI 能力”那 Makepad 值得你从现在开始关注。简单来说Tauri解决的是“高效交付客户端”egui解决的是“用 Rust 快速写出可交互 GUI”Makepad想解决的是“Rust 原生 UI 体系还能不能再往前走一步”这也是我开始认真看它的原因。下一篇我会继续写Makepad、egui、Dioxus、Tauri 到底怎么选。如果你已经用过这几个方案欢迎把你的真实体验写在评论区。吹也行喷也行但最好带项目场景不然很容易变成空对空。