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

查看 271|回复 34
作者:ninjaJ   
目前我的主力桌面端开发框架用 javafx ,简单点的用 electron ,但是各自有各自的缺点。
我司开发的主要是工业软件,涉及到串口通信等硬件交互,IO 密集、计算密集。但是我又很想用前端技术栈把 UI 分离出来( PS:原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等,各种绑定事件样板代码,写一个软件大部分时间都在写这些东西),可能主要还是已经习惯了前端技术栈那一套丰富的生态和灵活性。
选了一大圈好像还是基于 rust 的 Tauri 对我胃口,就是不知道它现在怎么样了,还有那么多坑吗?
subframe75361   
现在的最佳实践似乎是 electron + napi-rs
skye   
javafx 更好吧,毕竟 jni 和 jna 比 napi 还是成熟一些。
iugo   
Tauri 可以包含多个自己的服务端, 比如 Go 写个工具, 向外部暴露一个 HTTP 服务, Tauri 将其打包在内, Tauri 内部调用这个 HTTP 服务. Tauri 只做最简单的 UI 及渲染, 然后使用 Tauri 的工具链打包什么的, 任何复杂功能不需要重构, 只需要暴露出 HTTP 服务供调用就行.
ninjaJ
OP
  
@subframe75361 我的粗浅理解是 electron 和 Tauri 的 UI 层对我来说都一样,既然都用 napi-rs 了,为什么不直接上 Tauri 呢?您说的这个最佳实践评判的方式可以详细分享一下吗?
ninjaJ
OP
  
@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   
多窗口不成熟。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部