写 web 端界面写多了, 总感觉桌面的框架比如 QT, 用代码写起来非常麻烦.
主要是样式的调整吧, 比如 web 端可以直接用 chrome 的 devtools 调试样式, QT 这样的貌似就没有.
但是, 如果每个桌面产品都用 web 那套的话, 每一个都会套一个 electron, 一方面是打包会很大, 一方面用户也不喜欢.
业界貌似也没有一个统一多 electron 整合方案.
也简单找了下移动跨平台的框架. 最令人亲切的还是 React Native 吧. 但是实际使用才知道还是有差异, div 那些 web 标签没有了, 变成了 view 等.
另外类似桌面 F12 的 devtools 也比较难用.
======分割线======
不知道大家对上面的观点有啥看法
另外也想了解了各位使用的 GUI 技术栈与易用性
1
yiqiao 29 天前
目前用的是 golang 的 wails 。https://wails.io/ 桌面三端打包方便
或者可以看看 Rust 的 tauri 。https://tauri.app/ 当时用过 electron ,demo 打包出来就 180M 了,我直接 pass 了。 |
2
tsanie 29 天前
WinUI 或者 .NET MAUI/Xamarin.Forms 开发的话有 XAML Hot Reload
|
3
northluo 29 天前
@yiqiao golang 的一开始用的 fyne ,很多界面功能都不好做,包括列表下拉,二级列表展示点击啥的,后来用 pyqt 写的,还是 pyqt 实现起来方便很多,文档也够全
|
4
Vaspike 29 天前
我会推荐 kotlin compose desktop, 桌面端可以分发 win+ mac + linux(rpm 和 apt)
由 compose jetpack(安卓新一代官方框架)分化而来, 移植到手机端也比较可行 桌面端+ 移动端就变成了 Multiplatform 官网: https://www.jetbrains.com/compose-multiplatform/ 想快速了解代码的模样可以看我之前的一篇博客,结尾有成品截图: https://www.jetbrains.com/compose-multiplatform/ |
5
Vaspike 29 天前
|
6
mioktiar56 29 天前
对 C++er 来说,Qt 已经是非常便捷了;
对于调试,不能用写脚本的思维去看待编译型语言; |
7
Skifary 29 天前
QT 有一个 KDAB 出品的调试工具叫做 gammaray ,可以在运行时修改 QT 对象的属性
|
8
lisongeee 29 天前
虽然但是,kotlin compose desktop 和 electron 自带 chrome 一样
每一个都自带一个 jre ,你电脑里有多少应用就有多少个 jre ,并且 kotlin-native 目前处于不可用状态 |
9
shadowyue 29 天前
chromium 内核说不定会变成每个平台的必须装的依赖,这样就解决一切了
|
10
dimwoodxi27 29 天前
以前搞 javafx 感觉组件样式动画都挺丰富的,唯一缺点就是打包了,得带一个 jre ,而且和非常容易被解壳浏览源代码;再到后面用 go 的 fyne ,起码是直译的还能交叉编译,但组件库算是基础都有吧,样式啥的很局限性,编译大小通常为几 M 到几十 M ,总体感觉不如用 VB6 写的爽,编译才几百 KB ,但 VB6 追求美观也麻烦也不能像前两者一样跨平台
|
11
YUCOAT 29 天前
Qt 没有 devtools 调试界面确实有点方便。每当界面显示效果不符合我的预期的时候,我一般用 qss 给一些 QWidget 设置一个半透明的背景色的排查布局问题。
除此之外的问题解决起来还好,因为 IDE 有内置调试器,调试器功能一定程度上跟 devtools 的功能是重叠的。 |
12
tsanie 29 天前
@shadowyue #9 然后程序 A 依赖 >= 130.0.2849.52 ,程序 B 依赖 >= 120.0.6083.0 and < 121.0.6141.1 ,程序 C 依赖 <= 119.0.5998.1 /doge
|
13
iOCZS 29 天前
所有的问题都是因为不具备互操作性
|
16
mainjzb 29 天前
qt 相当复古。所以现代通常会考虑 flutter 方案或者其他 webview 调用方案。介于前两者目前成熟度只有 90%,商业上通常还是更倾向于用 electron
|
17
CLMan 29 天前
个人只对桌面 GUI 跨平台有些了解。
wails 和 tauri 都是基于桌面系统自带的 webview ,优点是不需要像 electron 那样每个应用带一个运行时,但较老的 Windows 系统,得自带运行时的安装包或者下载器,或者让用户手动安装运行时。webview 的缺点就是性能较差,首屏加载有 0.5s~1s 的延迟。 如果对桌面 GUI 的性能有追求,那用 flutter 不错,磁盘占用、内存占用、性能都很优秀。 Compose Multiplatform 本质上就是 Java GUI ,试用过两个基于其开发的产品,内存占用和磁盘占用表现较差。 |
18
CassianVale 29 天前
目前我是使用的 pyside6 开发跨平台应用,我也用过 electron-vite 做开发,但后来感觉 electron 打出的包太大,毕竟里面有个 chromium 内核,优势就是对前端比较友好,你也可以试试 flutter ,all in one ,但是对 web 端的支出做的不是特别好,而且有学习成本,安卓端要会 Java/Kotlin 、Dart 之类的语言,你可以看下这个 up 主对于 flutter 的分析,我觉得讲的挺好: https://www.bilibili.com/video/BV1D8411o71k
|
19
skallz 28 天前
@CassianVale 其实我感觉 electron 的最大优势是对一些复杂效果或者边缘场景的兼容做的非常好,很多其他技术实现起来非常困难的效果对于前端技术栈来说就几行代码,比如 qq 就有一部分原因是原先部分效果难以实现才将 ui 层换到 electron
|
20
timethinker 28 天前
过渡到直接用游戏引擎来做,啥效果都能实现,还能转行做游戏
|
21
shintendo 28 天前
你是否在找 Tauri
|
22
1una0bserver 28 天前 via Android
@lisongeee 有个用 graal 打包 compose desktop 的项目,可以看看: https://github.com/esp-er/compose-graal-hello
还有一种思路,就是 Webview 里跑 compose for Web |
23
lisongeee 28 天前
@1una0bserver #22
不是主流方案,基本没有什么人用,也没有官方的支持 compose for Web 只能管渲染,和本地交互用什么呢?并且只能用 kotlin 库,用不了 java 的生态 另外 Webview 兼容性如何呢?还得支持 wasmGc ,还不是得回到了 electron 路子 不可否认的事实是绝大多数用户根本不关心你用的啥 很多人连计算机基础都没有,只管打开点点就完了 在他们眼里 10MB 其实和 100MB 没什么区别,实现客户的功能才是首要的,谁管你用的什么技术 |
24
Yjhenan 28 天前
会 C#可以 avalonia 有中文文档,可以 aot 编译成独立无依赖 exe ,体积压缩下 10 兆不到
|
25
kevan 28 天前
aardio
|