2024 年了，兄弟们说说用 Tauri 遇到的哪些坑

[ninjaJ]

目前我的主力桌面端开发框架用 javafx ，简单点的用 electron ，但是各自有各自的缺点。

我司开发的主要是工业软件，涉及到串口通信等硬件交互，IO 密集、计算密集。但是我又很想用前端技术栈把 UI 分离出来（ PS：原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等，各种绑定事件样板代码，写一个软件大部分时间都在写这些东西），可能主要还是已经习惯了前端技术栈那一套丰富的生态和灵活性。

选了一大圈好像还是基于 rust 的 Tauri 对我胃口，就是不知道它现在怎么样了，还有那么多坑吗？

1 、关于兼容性，我会要求客户操作系统不低于 win10 。
2 、不会有太多的窗口创建和销毁。

补充说明一下：UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢？因为我的目标是构建一个灵活的产品架构，第一层是大量组合式、动态（比如动态列表）的前端交互面板；第二层是中间层，将前端的数据结构翻译成底层的执行命令；第三层是底层控制部分。通过这种方式将多参数、多任务、多设备统一起来，只需要一个客户端，用户可以通过这种组合式交互执行一系列的复杂控制。
那么虽然我的核心工作在第二层和第三层，但是工作量却在第一层，我希望提升的是这一部分。electron 无法支撑我的第三层，其他的选型无法满足我的第一层。

我另外还有 2 个问题有：
1 、我的实时高频（ 10ms 级）数据从 rust 传递到 webview 有没有性能问题，比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。
2 、诸位所说的 webview 的坑除了兼容性，还有哪些？大量数据图表的性能问题是否存在（不过这个我有数据层面的优化算法）？ webview 长期运行是否会越来越卡（对 GC 又爱又恨）？

[subframe75361]

现在的最佳实践似乎是 electron + napi-rs

[skye]

javafx 更好吧，毕竟 jni 和 jna 比 napi 还是成熟一些。

[iugo]

Tauri 可以包含多个自己的服务端, 比如 Go 写个工具, 向外部暴露一个 HTTP 服务, Tauri 将其打包在内, Tauri 内部调用这个 HTTP 服务. Tauri 只做最简单的 UI 及渲染, 然后使用 Tauri 的工具链打包什么的, 任何复杂功能不需要重构, 只需要暴露出 HTTP 服务供调用就行.

[ninjaJ]

@subframe75361 我的粗浅理解是 electron 和 Tauri 的 UI 层对我来说都一样，既然都用 napi-rs 了，为什么不直接上 Tauri 呢？您说的这个最佳实践评判的方式可以详细分享一下吗？

[ninjaJ]

@skye 我本身很擅长 java ，但是用 javafx 写的唯一的难受点是 UI 不够灵活高效，写的太难受了

[sunjiayao]

我目前碰到的问题可能就是 js api 有的比较简陋。比如读取剪切板只能读纯文本，做不到注册 windows 监听事件。需要用 rust 对接 windows api 。但用下来整体觉得没什么问题，可能是因为我大部分代码工作都在 rust 导致的。webview 基本只做 ui 展示。

然后由于我用的是 tauri 2.0 所以会有一些 bug ，不过目前都能绕过去。还未碰到卡住无法实现功能的问题。

[ZField]

可以试试 compose multiplatform for desktop ，ui 部分使用 kotlin 。其他的 Java 代码可以拿来就用

[per]

直接上 Twitter 上搜 yetone tauri

[lsk569937453]

多窗口不成熟。

[subframe75361]

@ninjaJ electron 的坑踩的差不多了，业务逻辑也是 js 写的快一些，工业软件包体积应该不是问题，总体开发效率比 tauri 高。如果 ui 只是简单交互，tauri 也可以胜任，只是目前没听说过有成熟的产品，多是一些小工具

[w568w]

> 原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等，各种绑定事件样板代码，写一个软件大部分时间都在写这些东西

可以试试 Flutter 或者楼上说的 Compose Multiplatform ，应该都独立于 Web 技术解决了这个阻碍。

> 串口通信等硬件交互，IO 密集、计算密集

Flutter 用的 Dart ，直接编译成原生代码，计算性能不会太差，但搞硬件交互可能要研究一下，估计要调第三方包； Kotlin 应该轻松一些。


> Tauri 对我胃口，就是不知道它现在怎么样了，还有那么多坑吗？

最大的问题是性能和兼容性差。我自己的不准确经验来看 Tauri 开发稍微大点的应用就会特别特别粘滞：冷启动慢、响应点击慢、拖动窗口慢、调整窗口大小卡，而且 Tauri 首次编译速度也慢得令人头秃（即便和 Electron 作比较，以上缺点也成立）；另外，因为一定要接系统的 Webview 库，写的时候也得注意兼容性问题。

[w568w]

补：Flutter 有 rust_bridge ，如果你一定想掺 Rust 进来，也不麻烦。

[vivisidea]

@per 哈哈，自从这哥被 tauri 坑了之后，疯狂反向安利 tauri😁

[subframe75361]

另外说一点，从我的个人体验上来说，tauri 的优势只有一个体积小。内存占用只要开着窗口就和 electron 没区别，启动体验在 windows 11 上不如 electron ，electron 在关闭 node 集成后也可以很安全

[duan602728596]

还是老老实实用 Electron 吧，真的。
我曾经也想过换其他框架，但是一想到用的东西，其他框架都不提供，就算了。

[roundgis]

知道 javafx 被用在工業軟件

還是有點意外的

[lisongeee]

js 写页面还有一个在开发页面速度上其它语言无法相比的优点啊

那就是配合声明式 ui 框架 react/vue 和构建工具 vite/webpack 可以有 hot module replace 即 HMR

效果就是更改一个组件的文件后，页面无需重启直接就能看到更新后的组件渲染效果，这对开发速度提升得不是一点半点啊

上面说的那些 javafx compose 受制于语言特性都没有这个功能(或者是残废)啊，大项目改一个文件编译尼玛大半天然后重启进程还得手动点击回到原来页面的位置才能看到效果

[mark2025]

@lisongeee 再配合上 TypeScript 提供的静态类型检查，真是很不错的

[hanaTsuk1]

可以等 2.0 正式版出来试试 2.0-alpha 到 beta 的改动还挺多

[xieren58]

工业用 c# , 库多, UI 可以用 https://avaloniaui.net/

[RogerL]

等 2.0 吧，感觉 2.0 改动太多了

[8520ccc]

真的没必要 tauri 对于旧版系统支持太拉了 无脑 electron

而且很多功能都不支持 生态不完善。。

[mayli]

@ZField 技术栈过于先进了, 考虑下传统的 imgui?

[xling]

运行不起来

[xiaocaiji111]

@ninjaJ 是的，javafx 一般都是一些类似工具类的东西再用，比如 dbeaver 啥的这种

[YetToCome]

涉及硬件最好不要轻易换技术栈，转换的坑短时间是填不上的。
jetbrains 那一套 Compose multiplatform 除了生态比较差以外，基本上是可用的

[hhacker]

尝鲜过 tauri, 最终还是回到 electron, 最终你想要的功能都是 tauri 没有但是 electron 有的

[ninjaJ]

@lisongeee 你的回答，戳中了我的心巴

[xclidongbo]

动了。这就 electron

[maplelin]

用 vue 和 react 开发 webview 没法用对应的开发者工具浏览器扩展

[ruchuby]

只要你不需要调用太多窗口、系统 API ，那 Tauri 完全可以代替 Electron 。我觉得目前毕竟麻烦的就是系统相关 API 的支持差一点。

可以看看我的 Tauri+Vue3 项目，用 Scrcpy Mask 像模拟器一样用鼠标键盘控制 Android 设备，基于 Tarui & Rust 开发的跨平台客户端： https://github.com/AkiChase/scrcpy-mask

[lmq2582609]

tauri 还挺好用的

[1una0bserver]

其实用 compose multiplatform 感觉是最稳妥的，都有 Java fx 代码了，迁移到 compose 绝对方便，而且也支持部分热重载。不过看你踌躇满志的样子，其实心里早就想拿 tauri+rust 重造轮子了吧？既然如此不妨试试，试一遍就知道了。不过仍然建议只要不是 UI 层的东西老老实实用 rust 写，少用 js ，小心埋 cve 。也可以考虑考虑编译到 wasm 的一些框架。还有远离系统菜单和托盘，这玩意经常出问题，不管是 kmp 还是 Web 都是。

[thtznet]

工业软件首选 C#，MAUI 一把梭

[catamaran]

desktop application ，为啥不用 c#?

[l1xnan]

纯写界面没啥坑，能在 rust 解决的也还好，就是中间如果你想突破 webview 的限制的时候各种坑，tauri 没有多少修改空间

[lisxour]

@8520ccc 因为 tauri 是直接调用系统自带浏览器内核，这种方案优缺点都非常明显

[ninjaJ]

@1una0bserver
1 、关于兼容性，我会要求客户操作系统不低于 win10 。
2 、不会有太多的窗口创建和销毁。

补充说明一下：UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢？因为我的目标是构建一个灵活的产品架构，第一层是大量组合式、动态（比如动态列表）的前端交互面板；第二层是中间层，将前端的数据结构翻译成底层的执行命令；第三层是控制部分。通过这种方式将多参数、多任务、多设备统一起来，只需要一个客户端，用户可以通过这种组合式交互执行一系列的复杂控制。

那么虽然我的核心工作在第一层和第二层，但是工作量却在第三层，我希望提升的是这一部分。electron 无法支撑我的第一层，其他的选型无法满足我的第三层。

我另外还有 2 个问题有：
1 、我的实时高频（ 10ms 级）数据从 rust 传递到 webview 有没有性能问题，比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。
2 、诸位所说的 webview 的坑除了兼容性，还有哪些？大量数据图表的性能问题是否存在（不过这个我有数据层面的优化算法）？ webview 长期运行是否会越来越卡（对 GC 又爱又恨）？

[ninjaJ]

`那么虽然我的核心工作在第一层和第二层，但是工作量却在第三层，我希望提升的是这一部分。electron 无法支撑我的第一层，其他的选型无法满足我的第三层。`
抱歉这段话的第一和第三层说反了 -> 核心工作在硬件侧，即第三层，electron 无法支撑。而工作量在视图层，即第一层，其他选项无法满足。

[zhouyg]

第三层为啥不写个单独的客户端，然后跟第一层第二层通过 IO 等方式进行调用

[zhouyg]

以二进制包的形式一个打包到客户端，对用的人来说还是只有一个客户端

[ninjaJ]

@zhouyg 我考虑过，这样做有一些弊端：1 、不同语言互相调用会提升复杂度（包括但不仅限于错误传递、打包部署、兼容性问题） 2 、这种互相调用方式会引入新的问题（如自定义协议、时延或者锁的问题，以上分别对应了不同的方案）。
可能是我的需求掣肘比较多吧。
另外，做软件不仅要考虑技术难度，还要考虑工程效率。