这是一个创建于 136 天前的主题，其中的信息可能已经有所发展或是发生改变。
有类似的 rust UI 库观摩下吗?
第 1 条附言 · 2025 年 9 月 8 日
## 使用 rust 制作 UI 特性:
### 缺点
1. **开发效率不占优**
- 相比 HTML 、CSS 等，开发速度未必更快，使用宏生成 HTML 时，IDE 对宏的支持差，缺乏智能提示。
- 实现相同特性可能需要更多代码量，且 UI 开发中共享状态等需求与 Rust 的特性存在冲突，往往需要引入 ECS 架构，反而降低生产力。
2. **Web 端局限性明显**
- Rust 并非浏览器上的一等公民，代码最终需编译为 HTML + CSS + JavaScript/ webcomponents ，性能可能受影响。
3. **性能瓶颈不在语言本身**：UI 性能瓶颈多在渲染层、硬件层或 DOM 等，而非操作它们的语言，JavaScript 在这方面不算慢。
4. **兼容性和生态问题**：跨平台兼容性需考虑，对前端众多功能特性的支持程度有限，相关生态不如传统 UI 开发语言成熟。
5. **替代现有方案优势不足**：在 GUI 领域，已有 C++、QT 、Flutter 、Unity 、Godot 等成熟方案，Rust 替代它们的优势不明显；若要提升性能，重写 V8 引擎或浏览器内核更有意义，单纯用 Rust 制作 UI 意义不大。
6. **存在“为了用 Rust 而用 Rust”的风险**：可能因过度追求技术而忽视实际需求和开发效率。
### 优点
1. **安全性较好**：Rust 语言本身具有内存安全等特性，用其制作 UI 可能在安全性方面有优势。
3. **存在相关库和工具**：如 Dioxus 、Yew 、Iced 等库，以及 Zed 开源的 GPUI 等，可用于 Rust 开发 UI ，且部分库（如即将发布 0.7 版本的 Dioxus ）支持类似 React 的开发方式和热重载。
4. **在特定场景有潜力**：对于车机等追求稳定性与速度的场景，有一定的探索价值；在 imgui 开发方面有一定优势，也可结合 webgl/webgpu+svg 或 webcomponent 实现特定效果。
5. **跨平台潜力**：部分 Rust UI 库（如 Iced ）专注注于跨平台开发，可能具备跨平台特性。
### 缺点
1. **开发效率不占优**
- 相比 HTML 、CSS 等，开发速度未必更快，使用宏生成 HTML 时，IDE 对宏的支持差，缺乏智能提示。
- 实现相同特性可能需要更多代码量，且 UI 开发中共享状态等需求与 Rust 的特性存在冲突，往往需要引入 ECS 架构，反而降低生产力。
2. **Web 端局限性明显**
- Rust 并非浏览器上的一等公民，代码最终需编译为 HTML + CSS + JavaScript/ webcomponents ，性能可能受影响。
3. **性能瓶颈不在语言本身**：UI 性能瓶颈多在渲染层、硬件层或 DOM 等，而非操作它们的语言，JavaScript 在这方面不算慢。
4. **兼容性和生态问题**：跨平台兼容性需考虑，对前端众多功能特性的支持程度有限，相关生态不如传统 UI 开发语言成熟。
5. **替代现有方案优势不足**：在 GUI 领域，已有 C++、QT 、Flutter 、Unity 、Godot 等成熟方案，Rust 替代它们的优势不明显；若要提升性能，重写 V8 引擎或浏览器内核更有意义，单纯用 Rust 制作 UI 意义不大。
6. **存在“为了用 Rust 而用 Rust”的风险**：可能因过度追求技术而忽视实际需求和开发效率。
### 优点
1. **安全性较好**：Rust 语言本身具有内存安全等特性，用其制作 UI 可能在安全性方面有优势。
3. **存在相关库和工具**：如 Dioxus 、Yew 、Iced 等库，以及 Zed 开源的 GPUI 等，可用于 Rust 开发 UI ，且部分库（如即将发布 0.7 版本的 Dioxus ）支持类似 React 的开发方式和热重载。
4. **在特定场景有潜力**：对于车机等追求稳定性与速度的场景，有一定的探索价值；在 imgui 开发方面有一定优势，也可结合 webgl/webgpu+svg 或 webcomponent 实现特定效果。
5. **跨平台潜力**：部分 Rust UI 库（如 Iced ）专注注于跨平台开发，可能具备跨平台特性。
 |
1
duanxianze 2025 年 9 月 1 日  9
啊？魔怔了啊，现有的任何语言做 ui 都不会比 html css 更快
|
 |
2
chenxiaolani 2025 年 9 月 1 日
有意义嘛，
|
 |
3
nkidgm 2025 年 9 月 1 日 1
没意义，除非想统一技术栈，一门语言走天下。
|
 |
4
githmb 2025 年 9 月 1 日 1
不会快，一般都是宏来生成 html ，但是现在 IDE 对宏的支持太差了，没有智能提示
|
 |
5
binhb 2025 年 9 月 1 日
|
 |
6
xFrye 2025 年 9 月 1 日 3
不会，不要为了 rust 而 rust
|
 |
7
skyworker 2025 年 9 月 1 日 5
手里只有一把锤子, 然后感觉所有的问题都是钉子
|
 |
8
musi 2025 年 9 月 1 日
rust 在浏览器上不是一等公民，所以你的 rust 代码最终会被转义成 HTML + CSS + JavaScript
|
 |
9
zhhcnn 2025 年 9 月 1 日
瓶颈在 dom 而不是操作 dom 的语言，js 真不算慢了
|
 |
10
QlanQ 2025 年 9 月 1 日
平时觉得慢的地方，主要是 浏览器渲染 dom 慢吧
|
 |
11
jspatrick 2025 年 9 月 1 日
你指的是开发快还是运行快？开发快还能快过 html css ？运行快似乎也不在乎这点。。。
|
 |
12
cwliang 2025 年 9 月 1 日 1
这是正经前端问的问题？
|
 |
13
penisulaS 2025 年 9 月 1 日
我还以为是 gui,原来指的是 web 前端吗
|
 |
14
rb6221 2025 年 9 月 1 日
速度瓶颈不在 UI 库，在渲染层，甚至硬件层
|
 |
15
shui14 2025 年 9 月 1 日
如果做 imgui ，值得。否则不比 html 有优势，除非你有特殊需求，另外 webgl/webgpu+svg 或者 webcompontent 也可以做 html 版的 imgui ，把那个 pdfjs 的 layout 移植过来就行，甚至在 react 还在 createclass 时代就有人这么干过，把 ios 的布局移植的，相当于实现了在 webgl2 上的 flex 。再早之前，有个 react-canvas ，你搜一下思路一样的。前几年流行的长 table ，某个库 canvas table 可以说就从这里来的。无非现在准备 rust 替代，这个成本就看值不值，技术上肯定是可行的，十年前创业浪潮就有过很多五花八门的，而且不少公司现在就在这么干
|
 |
16
mizuki9 2025 年 9 月 1 日 2
用 rust 原生，要考虑跨平台兼容性，要考虑前端非常多的功能特性能支持多少，做到同样的特性需要的代码量是不是值得
|
 |
17
wangtian2020 2025 年 9 月 1 日
没有意义的快，leetcode 我能花 10 分钟写倒数 10%内存占用/倒数 10%CPU 使用 的答案，我就不会花 1 小时去写 前 10% 的答案
|
 |
18
hwdq0012 2025 年 9 月 1 日
gui 这块，win32 , android ndk, mac/ios object c ， 哪个不是 c++，非要搞 rust
|
 |
19
frank42a 2025 年 9 月 1 日 1
作死
|
 |
20
bgm004 2025 年 9 月 1 日
啊？是我没看懂吗？不管你拿什么写，最后跑的不还是 html ，css ，js ？怎么个快法？
|
 |
21
ZZITE 2025 年 9 月 1 日
|
 |
22
webszy 2025 年 9 月 1 日
你拿 rust 写一个游览器内核，然后只能渲染 rust 代码不就行了
|
 |
23
usVexMownCzar 2025 年 9 月 1 日 via iPhone
rust 写一个超过 V8 的引擎。有搞头。
或者 rust 重写 V8 😁 |
 |
24
FlashEcho 2025 年 9 月 1 日
rust 也没法直接写 UI 啊，要硬写需要需要编译成 web components 之类的东西，性能会更差
你看现在主流的 UI 库，对应多个框架，都是有多个版本的，就是为了借用框架本身的运行时提高性能，你直接不管这个了，肯定是不行的 |
 |
25
flyqie 2025 年 9 月 1 日 via Android
要想快的话建议 rust 重写 v8 ，不然用 rust 没有什么意义，也不会快
|
 |
26
yigefanqie 2025 年 9 月 1 日
建议用 rust 去写一个浏览器内核，就快了。
|
 |
27
irisdev 2025 年 9 月 1 日
这个问题跟之前在 v 站上看到的问题。“为什么前端不用 rpc 调用后端”有异曲同工之妙
|
 |
28
Sezxy 2025 年 9 月 1 日
你说的是不是 tauri
|
 |
29
TsukiHa 2025 年 9 月 1 日
但凡有能用的 rust UI ，大概 zed 也不用从 0 写一个把
|
 |
30
iorilu 2025 年 9 月 1 日
你说的前端是指 web 端还是说图形界面 gui 那种
|
 |
31
lizy0329 OP 我想看看,现在的车机 UI, 如果追求稳定性与速度, 是不是使用 rust 来制作 UI 比较靠谱点
|
 |
33
daniel11 2025 年 9 月 1 日 1
可以看看 zed 开源的 GPUI ，长桥开源了一个 GPUI 的组件库 https://github.com/longbridge/gpui-component?tab=readme-ov-file ， 看他们基于这个组件库做的 股票交易 客户端还行
|
 |
34
liuidetmks 2025 年 9 月 1 日
你肯定是鸡丁
|
 |
35
iliaoliao 2025 年 9 月 2 日 1
可以看看 dioxus 快要发布的 0.7 版本，和写 react 差不多，开发 native 的时候支持热重载。很强。
|
 |
36
labdum 2025 年 9 月 2 日
webkit 和 blink 都是 c++写的吧。rust 也不会更快，顶多安全点。
如果是机车 UI 也可以用 swift 吧，swift 现在也有在做嵌入式的开发。 |
 |
37
linkopeneyes 2025 年 9 月 2 日
@iorilu #32 车机不是还有很多直接 unity 和 godot 的吗
|
 |
38
charlie21 2025 年 9 月 2 日
https://github.com/iced-rs/iced
cross-platform GUI library for Rust focused on simplicity and type-safety |
 |
39
Chuckle 2025 年 9 月 3 日
期待 rustscript
|
 |
40
Ketteiron 2025 年 9 月 3 日
@Chuckle #39 我想象中的 rustscript 差不多长这样
let a: Owned<string> = "hello" let b = a console.log(a) // 编译失败 let c: Shared<string> = "world" let d = c console.log(c) // 编译成功 const e = (s: &string) => {} const f = (s: &mut string) => {} // 异步生命周期 async function g<'async>(data: &'async data) {} // 安全访问 dom 元素 document.getElementById("h")?.with_mut(|el| el.textContent = "hello world") |
 |
41
hez2010 2025 年 9 月 3 日 1
简单的 hello world 可以，但是但凡正经一点的 UI 用 rust 就是自找不痛快，包括游戏、GUI 都是同理。
UI 的特性天生就是共享状态需要允许多方同时持有非只读引用，然而 Rust 不会允许你这么做，于是最后你不得不把整个 ECS 那套搬进 GUI 开发里，最后带来的反而是生产力下降。 |
|
42
lizy0329 OP @hez2010 我找到了这篇文章 [Entity-Component-System architecture for UI in Rust]( https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html)
|
Select Language