从 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 用 WebView2，macOS 用WKWebView，Linux 用webkit2gtk。这也是它为什么能保持较小体积、上手又快的原因之一。
来源：Tauri 官方文档

• https://v2.tauri.app/start/
• https://v2.tauri.app/reference/webview-versions/

说白了，Tauri 解决的是一个非常现实的问题：

我想快速做出一个像样的跨平台客户端，而且我已经有现成的前端经验。

这个场景下，Tauri 几乎没有什么理由不进候选名单。

2. Tauri 很强，但它解决的不是全部问题

我以前看桌面方案的时候，默认动作就是：

1. 先看能不能用 Web 技术复用现有团队能力。
2. 如果能，优先 Tauri。
3. 如果要性能、复杂渲染、图形交互，再考虑别的。

这个决策没毛病。问题在于，你做得越深，就越容易发现“能做”和“适合做”不是一回事。

举个例子。

如果你做的是：

• 设置面板
• 笔记工具
• 表单型业务客户端
• 简单的数据管理后台

那 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 runtime
• Rust-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 细节。

但对大多数人来说，真正重要的问题其实是前两个：

1. 它到底解决什么问题？
2. 它和我已知的那几条路有什么本质区别？

所以这个系列我会按下面的顺序往下写：

1. 为什么是 Rust GUI，为什么关注 Makepad
2. Makepad 和 egui、Dioxus、Tauri 到底怎么选
3. 从零跑起第一个 Makepad 项目
4. Makepad 的 UI 代码到底该怎么读

先把判断框架搭起来，再进具体代码，会顺很多。

总结

最后收个尾。

如果你只是想找一条最快落地的跨平台客户端路线，Tauri 依然非常强。

但如果你在意的不是“把前端打包成桌面应用”，而是“Rust 自己能不能长出真正像样的客户端 UI 能力”，那 Makepad 值得你从现在开始关注。

简单来说：

• Tauri解决的是“高效交付客户端”
• egui解决的是“用 Rust 快速写出可交互 GUI”
• Makepad想解决的是“Rust 原生 UI 体系还能不能再往前走一步”

这也是我开始认真看它的原因。

下一篇我会继续写：Makepad、egui、Dioxus、Tauri 到底怎么选。

如果你已经用过这几个方案，欢迎把你的真实体验写在评论区。吹也行，喷也行，但最好带项目场景，不然很容易变成空对空。