Makepad 1.0：用 Rust 与 Splash DSL 打造、面向 AI 生成 UI 的跨平台框架
阅读时间: 大约 8 分钟
Makepad 1.0：用 Rust 与 Splash DSL 打造、面向 AI 生成 UI 的跨平台框架
跨平台 UI 这块地，Tauri、React Native、Flutter 各有山头。Makepad 走的是一条更硬核的路：纯 Rust、Shader 驱动渲染，并在 1.0 时把定位进一步收束到”让 AI 能生成、流式检查、修改 UI 代码”。本文基于 makepad.nl 官方站梳理它的能力与边界。
一、背景：从 2019 到 AI 时代的转向
Makepad 始于 2019 年，最初是一个 Rust GUI 实验项目。如今官方明确说它正在转型为一个更宽泛的开源项目，围绕三件事：Rust UI、AI 辅助开发、以及 Splash（一套实时可读的 UI DSL）。这个转向很值得注意——它不只是”再做一个 GUI 库”，而是把”AI 生成 UI 代码”当成了一等公民。
二、是什么：Shader 架构 + Splash DSL
Makepad 采用基于 Shader 的架构来绘制 UI，因此既能做复杂 2D，也能上 3D、VR/AR。它的目标平台覆盖 Windows、Linux、macOS、iOS、Android，并通过 WebAssembly 在浏览器运行（官方标注支持 Chrome、Safari 17+、Firefox）。
它的声明式设计语言叫 Splash：一种紧凑描述屏幕、组件、布局与样式的 DSL，关键卖点是”live readable”——人读得懂，AI 也生成得出来。官方的逻辑链条很清晰：Rust 给 AI 生成的代码一个快速且诊断严格的编译目标，强类型、所有权、分层错误信息能帮助生成的 UI 代码快速收敛到正确 API；同时产物依然是高性能原生软件。
三、演示能力：从表格到 DJ 到世界地图
官网上线了一组可在浏览器里跑的 WebAssembly 演示（官方注明是桌面应用的精简版）：
| 演示 | 展示的能力 |
|---|---|
| 个人理财 | 净值曲线、账户分类、预算与报表（上图） |
| 电子表格 | 实时公式、填充柄、撤销、TSV 剪贴板 |
| 文件管理器 | 模拟 38,000 文件、多视图、Quick Look、磁盘占用 treemap（上图） |
| DJ/VJ | 实时分轨分离、key lock、EQ、beat sync、视频特效 |
| 矢量地图 | 从 230 GB 世界档案按字节范围流式加载、地点搜索与路由 |
| 乐谱 | 巴赫/贝多芬等八首钢琴演奏的乐谱渲染与回放 |
这组演示的跨度很大——从表格 treemap 到音频处理再到 230 GB 地图流，目的是证明 Shader 驱动 + Rust 在性能上的上限。
四、关键信息速览
| 项目 | 官方口径 |
|---|---|
| 版本 | 1.0 |
| 语言 | Rust |
| 渲染 | 基于 Shader 的架构 |
| 平台 | Windows / Linux / macOS / iOS / Android / Web(WASM) |
| UI DSL | Splash（实时可读，面向 AI 生成） |
| 项目起点 | 2019 年，现转向更宽的开源 UI 生态 |
| Web 浏览器要求 | Chrome、Safari 17+、Firefox（演示为桌面版精简） |
把 Makepad 放进已有格局里对比，取舍会更清楚。和 Tauri 比：Tauri 的思路是复用系统 WebView——写 HTML/CSS/JS，套一层 Rust 壳，轻量、能直接吃整个 Web 前端生态；代价是 UI 受 WebView 能力约束，复杂自绘、像素级一致与高帧率动画要和 WebView 的种种限制搏斗。Makepad 走的是反面：自己用 shader 把每个像素画出来，不依赖 WebView，跨端像素一致性与渲染上限更高，但代价是控件、排版、样式体系都得自建，享受不到 Web/CSS 那套现成生态。和 Flutter 比：两者都是”自绘引擎跨端”，Flutter 用 Dart + Skia/Impeller、生态成熟，Makepad 则押在 Rust + 自定义 shader 栈上——语言与生态取舍不同。
对它的两个核心卖点也要留个心眼。其一，“Shader 架构性能强”是设计上的上限优势，不等于日常业务 UI 都跑得更快——大多数后台表单根本用不满 GPU，自绘反而增加维护成本。其二，“面向 AI 生成 UI”目前更像战略叙事：官网那组精致演示是人工打磨的样例，而非”AI 批量生成并真实交付”的公开证据；Splash 是否真能让大模型稳定产出可编译、可维护的界面，仍需社区在实战里验证。
值得一提的是它在 Web 端的取舍逻辑。那组 WASM 演示能在浏览器里跑表格、DJ、甚至 230 GB 的矢量地图，靠的不是把桌面功能整包塞进去，而是按需、流式地取数据——比如地图按字节范围（byte range）从远端档案拉取，而不是一次性下载整个瓦片。这种”原生端能力直接平移到 Web”的思路，是 Makepad 自绘渲染的红利；但官方也明说了浏览器里跑的是桌面应用的精简版，像 DJ 的实时分轨、乐谱回放这类重负载，在 WASM 里能跑到什么程度，仍要以真实设备实测为准，不能被演示的流畅观感带偏。
五、优势与局限
优势：
- 真·跨单一代码库：从桌面到移动到 WASM，一套 Rust 代码；
- Shader 性能上限高：2D/3D/音视频/大地图流式都能扛，适合富交互、数据密集 UI；
- Splash 面向 AI 生成：在”AI 写 UI”的趋势下，可读 DSL + Rust 强诊断是差异化思路；
- 迭代体验：官方称编译快、支持免重编译的实时样式调整。
局限（需客观看待）：
- 浏览器演示是精简版：WASM 里跑的不是完整桌面功能，不能据此判断 Web 端等价能力；
- 生态年轻：1.0 刚发布，现成组件库、第三方教程远不如成熟工具链；
- Shader/DSL 学习曲线：GPU 驱动 UI 不是所有团队都需要，也不是所有设计师都能上手；
- AI 优先是战略押注：把”AI 生成 UI”当核心卖点很新，但这一方向的成熟度与实际开发效率仍需时间验证。
六、谁该关注
- Rust 团队想做高性能、跨桌面+移动+Web 的富交互 UI：Makepad 的 shader 模型有优势；
- 在探索”AI 生成原生界面”工作流的团队：Splash DSL 是一个值得研究的样本；
- 需要处理大文件、实时音视频、数据可视化的桌面应用；
- 只想要成熟组件生态、快速套标准业务后台的项目：建议继续选更成熟的工具链。