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

[ninjaJ]

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

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

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

[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 等方式进行调用