这是一个创建于 197 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前我的主力桌面端开发框架用 javafx ，简单点的用 electron ，但是各自有各自的缺点。
我司开发的主要是工业软件，涉及到串口通信等硬件交互，IO 密集、计算密集。但是我又很想用前端技术栈把 UI 分离出来（ PS：原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等，各种绑定事件样板代码，写一个软件大部分时间都在写这些东西），可能主要还是已经习惯了前端技术栈那一套丰富的生态和灵活性。
选了一大圈好像还是基于 rust 的 Tauri 对我胃口，就是不知道它现在怎么样了，还有那么多坑吗？
第 1 条附言 · 196 天前
1 、关于兼容性，我会要求客户操作系统不低于 win10 。
2 、不会有太多的窗口创建和销毁。
补充说明一下：UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢？因为我的目标是构建一个灵活的产品架构，第一层是大量组合式、动态（比如动态列表）的前端交互面板；第二层是中间层，将前端的数据结构翻译成底层的执行命令；第三层是底层控制部分。通过这种方式将多参数、多任务、多设备统一起来，只需要一个客户端，用户可以通过这种组合式交互执行一系列的复杂控制。
那么虽然我的核心工作在第二层和第三层，但是工作量却在第一层，我希望提升的是这一部分。electron 无法支撑我的第三层，其他的选型无法满足我的第一层。
我另外还有 2 个问题有：
1 、我的实时高频（ 10ms 级）数据从 rust 传递到 webview 有没有性能问题，比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。
2 、诸位所说的 webview 的坑除了兼容性，还有哪些？大量数据图表的性能问题是否存在（不过这个我有数据层面的优化算法）？ webview 长期运行是否会越来越卡（对 GC 又爱又恨）？
2 、不会有太多的窗口创建和销毁。
补充说明一下：UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢？因为我的目标是构建一个灵活的产品架构，第一层是大量组合式、动态（比如动态列表）的前端交互面板；第二层是中间层，将前端的数据结构翻译成底层的执行命令；第三层是底层控制部分。通过这种方式将多参数、多任务、多设备统一起来，只需要一个客户端，用户可以通过这种组合式交互执行一系列的复杂控制。
那么虽然我的核心工作在第二层和第三层，但是工作量却在第一层，我希望提升的是这一部分。electron 无法支撑我的第三层，其他的选型无法满足我的第一层。
我另外还有 2 个问题有：
1 、我的实时高频（ 10ms 级）数据从 rust 传递到 webview 有没有性能问题，比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。
2 、诸位所说的 webview 的坑除了兼容性，还有哪些？大量数据图表的性能问题是否存在（不过这个我有数据层面的优化算法）？ webview 长期运行是否会越来越卡（对 GC 又爱又恨）？
44 条回复 • 2024-11-11 09:46:02 +08:00
 |
1
subframe75361 197 天前 via Android
现在的最佳实践似乎是 electron + napi-rs
|
 |
2
skye 197 天前
javafx 更好吧，毕竟 jni 和 jna 比 napi 还是成熟一些。
|
 |
3
iugo 197 天前
Tauri 可以包含多个自己的服务端, 比如 Go 写个工具, 向外部暴露一个 HTTP 服务, Tauri 将其打包在内, Tauri 内部调用这个 HTTP 服务. Tauri 只做最简单的 UI 及渲染, 然后使用 Tauri 的工具链打包什么的, 任何复杂功能不需要重构, 只需要暴露出 HTTP 服务供调用就行.
|
 |
4
ninjaJ OP @subframe75361 我的粗浅理解是 electron 和 Tauri 的 UI 层对我来说都一样，既然都用 napi-rs 了，为什么不直接上 Tauri 呢？您说的这个最佳实践评判的方式可以详细分享一下吗？
|
 |
6
sunjiayao 197 天前
我目前碰到的问题可能就是 js api 有的比较简陋。比如读取剪切板只能读纯文本，做不到注册 windows 监听事件。需要用 rust 对接 windows api 。但用下来整体觉得没什么问题，可能是因为我大部分代码工作都在 rust 导致的。webview 基本只做 ui 展示。
然后由于我用的是 tauri 2.0 所以会有一些 bug ，不过目前都能绕过去。还未碰到卡住无法实现功能的问题。 |
 |
7
ZField 197 天前  1
可以试试 compose multiplatform for desktop ，ui 部分使用 kotlin 。其他的 Java 代码可以拿来就用
|
 |
8
per 197 天前 via iPhone 1
直接上 Twitter 上搜 yetone tauri
|
 |
9
lsk569937453 197 天前
多窗口不成熟。
|
|
10
subframe75361 197 天前 via Android
@ninjaJ electron 的坑踩的差不多了，业务逻辑也是 js 写的快一些，工业软件包体积应该不是问题，总体开发效率比 tauri 高。如果 ui 只是简单交互，tauri 也可以胜任，只是目前没听说过有成熟的产品，多是一些小工具
|
 |
11
w568w 197 天前
> 原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等，各种绑定事件样板代码，写一个软件大部分时间都在写这些东西
可以试试 Flutter 或者楼上说的 Compose Multiplatform ，应该都独立于 Web 技术解决了这个阻碍。 > 串口通信等硬件交互，IO 密集、计算密集 Flutter 用的 Dart ，直接编译成原生代码，计算性能不会太差，但搞硬件交互可能要研究一下，估计要调第三方包； Kotlin 应该轻松一些。 > Tauri 对我胃口，就是不知道它现在怎么样了，还有那么多坑吗？ 最大的问题是性能和兼容性差。我自己的不准确经验来看 Tauri 开发稍微大点的应用就会特别特别粘滞：冷启动慢、响应点击慢、拖动窗口慢、调整窗口大小卡，而且 Tauri 首次编译速度也慢得令人头秃（即便和 Electron 作比较，以上缺点也成立）；另外，因为一定要接系统的 Webview 库，写的时候也得注意兼容性问题。 |
|
12
w568w 197 天前
补：Flutter 有 rust_bridge ，如果你一定想掺 Rust 进来，也不麻烦。
|
|
14
subframe75361 197 天前 via Android
另外说一点，从我的个人体验上来说，tauri 的优势只有一个体积小。内存占用只要开着窗口就和 electron 没区别，启动体验在 windows 11 上不如 electron ，electron 在关闭 node 集成后也可以很安全
|
 |
15
duan602728596 197 天前
还是老老实实用 Electron 吧，真的。
我曾经也想过换其他框架，但是一想到用的东西，其他框架都不提供，就算了。 |
 |
16
roundgis 197 天前 via Android
知道 javafx 被用在工業軟件
還是有點意外的 |
 |
17
lisongeee 197 天前 2
js 写页面还有一个在开发页面速度上其它语言无法相比的优点啊
那就是配合声明式 ui 框架 react/vue 和构建工具 vite/webpack 可以有 hot module replace 即 HMR 效果就是更改一个组件的文件后，页面无需重启直接就能看到更新后的组件渲染效果，这对开发速度提升得不是一点半点啊 上面说的那些 javafx compose 受制于语言特性都没有这个功能(或者是残废)啊，大项目改一个文件编译尼玛大半天然后重启进程还得手动点击回到原来页面的位置才能看到效果 |
 |
19
hanaTsuk1 197 天前
可以等 2.0 正式版出来试试 2.0-alpha 到 beta 的改动还挺多
|
 |
20
xieren58 197 天前
工业用 c# , 库多, UI 可以用 https://avaloniaui.net/
|
 |
21
RogerL 197 天前
等 2.0 吧，感觉 2.0 改动太多了
|
 |
22
8520ccc 197 天前
真的没必要 tauri 对于旧版系统支持太拉了 无脑 electron
而且很多功能都不支持 生态不完善。。 |
 |
24
xling 197 天前
运行不起来
|
 |
25
xiaocaiji111 197 天前
@ninjaJ 是的，javafx 一般都是一些类似工具类的东西再用，比如 dbeaver 啥的这种
|
 |
26
YetToCome 197 天前
涉及硬件最好不要轻易换技术栈，转换的坑短时间是填不上的。
jetbrains 那一套 Compose multiplatform 除了生态比较差以外，基本上是可用的 |
 |
27
hhacker 197 天前
尝鲜过 tauri, 最终还是回到 electron, 最终你想要的功能都是 tauri 没有但是 electron 有的
|
 |
29
xclidongbo 197 天前
动了。这就 electron
|
 |
30
maplelin 197 天前
用 vue 和 react 开发 webview 没法用对应的开发者工具浏览器扩展
|
 |
31
ruchuby 197 天前
只要你不需要调用太多窗口、系统 API ，那 Tauri 完全可以代替 Electron 。我觉得目前毕竟麻烦的就是系统相关 API 的支持差一点。
可以看看我的 Tauri+Vue3 项目，用 Scrcpy Mask 像模拟器一样用鼠标键盘控制 Android 设备，基于 Tarui & Rust 开发的跨平台客户端： https://github.com/AkiChase/scrcpy-mask |
 |
32
lmq2582609 197 天前
tauri 还挺好用的
|
 |
33
1una0bserver 197 天前 via Android
其实用 compose multiplatform 感觉是最稳妥的，都有 Java fx 代码了，迁移到 compose 绝对方便，而且也支持部分热重载。不过看你踌躇满志的样子，其实心里早就想拿 tauri+rust 重造轮子了吧？既然如此不妨试试，试一遍就知道了。不过仍然建议只要不是 UI 层的东西老老实实用 rust 写，少用 js ，小心埋 cve 。也可以考虑考虑编译到 wasm 的一些框架。还有远离系统菜单和托盘，这玩意经常出问题，不管是 kmp 还是 Web 都是。
|
 |
34
thtznet 197 天前
工业软件首选 C#，MAUI 一把梭
|
 |
35
catamaran 197 天前
desktop application ，为啥不用 c#?
|
 |
36
l1xnan 196 天前
纯写界面没啥坑，能在 rust 解决的也还好，就是中间如果你想突破 webview 的限制的时候各种坑，tauri 没有多少修改空间
|
|
38
ninjaJ OP @1una0bserver
1 、关于兼容性，我会要求客户操作系统不低于 win10 。 2 、不会有太多的窗口创建和销毁。 补充说明一下：UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢？因为我的目标是构建一个灵活的产品架构，第一层是大量组合式、动态（比如动态列表）的前端交互面板；第二层是中间层，将前端的数据结构翻译成底层的执行命令；第三层是控制部分。通过这种方式将多参数、多任务、多设备统一起来，只需要一个客户端，用户可以通过这种组合式交互执行一系列的复杂控制。 那么虽然我的核心工作在第一层和第二层，但是工作量却在第三层，我希望提升的是这一部分。electron 无法支撑我的第一层，其他的选型无法满足我的第三层。 我另外还有 2 个问题有： 1 、我的实时高频（ 10ms 级）数据从 rust 传递到 webview 有没有性能问题，比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。 2 、诸位所说的 webview 的坑除了兼容性，还有哪些？大量数据图表的性能问题是否存在（不过这个我有数据层面的优化算法）？ webview 长期运行是否会越来越卡（对 GC 又爱又恨）？ |
|
39
ninjaJ OP `那么虽然我的核心工作在第一层和第二层，但是工作量却在第三层，我希望提升的是这一部分。electron 无法支撑我的第一层，其他的选型无法满足我的第三层。`
抱歉这段话的第一和第三层说反了 -> 核心工作在硬件侧，即第三层，electron 无法支撑。而工作量在视图层，即第一层，其他选项无法满足。 |
 |
40
zhouyg 195 天前
第三层为啥不写个单独的客户端，然后跟第一层第二层通过 IO 等方式进行调用
|
|
41
zhouyg 195 天前
以二进制包的形式一个打包到客户端，对用的人来说还是只有一个客户端
|
|
42
ninjaJ OP @zhouyg 我考虑过，这样做有一些弊端：1 、不同语言互相调用会提升复杂度（包括但不仅限于错误传递、打包部署、兼容性问题） 2 、这种互相调用方式会引入新的问题（如自定义协议、时延或者锁的问题，以上分别对应了不同的方案）。
可能是我的需求掣肘比较多吧。 另外，做软件不仅要考虑技术难度，还要考虑工程效率。 |
 |
43
KyleCommon 53 天前
@ninjaJ 老哥，你最后选择了什么平台？
|
|
44
ninjaJ OP @KyleCommon
最后还是用了 Tauri ，巨爽。就是要花点时间学习 Rust 。程序框架和结构设计自己来，逻辑代码一大半使用的 Claude 生成，中间会有一些坑但是好在都解决了。 我的项目花了一个月切换过来的，我的总结是，在 AI 的加持下已经可以实现大部分应用 99%的功能了，但是如果应用有一定复杂度和技术难度，那需要对 Rust 非常精深，这时的难度会陡增。 综上，还是需要根据自己的需要来选择，权衡利弊。 |
Select Language