C++ 和 C# 哪个容易开发出用户体验好（占用资源小&好看&稳定&反应快）的跨 macOS/Windows 平台的桌面程序？

[rv54ntjwfm3ug8]

Electron 不考虑，没见过用 Electron 写的用户体验好的程序，公认优化好的 VS Code 启动也很慢，剩余内存一不够就卡得要死。

目前是有一点 C++ Qt 和 C# WinForm 开发经验。想写一个桌面程序，因为比较喜欢 C#（很多功能都不用自己实现，而且我更熟悉一点），而且听说 C# 的 Avalonia 框架可以用来非常方便地开发好看的跨平台 GUI 程序，于是打算用 C#来写。但 Google 了一下，很多人说 Avalonia 在 macOS 上有很多 non-native 行为，例如复制键变成了 Control-C 而不是 macOS 默认的 Command-C ，而且不是很稳定，经常崩溃，也没有什么知名开源项目在用，资料不好找。想问问 C++ 和 C# 哪个容易开发出用户体验好（好看&稳定&反应快&占用资源小）的跨 macOS/Windows 平台的桌面程序？或是还有什么更好的方案？

好看很重要，最好能方便地实现一些过渡动画。

[ikas]

并没有.真想要体验.就是各自原生,,业务核心采用 c++,然后可以跨平台编译

ui 部分就是各自原生

[WebKit]

为什么不考虑 flutter 呢。兼顾开发速度和用户体验

[wzzzx]

Qt 吧，上 QML 开发速度很快

[rv54ntjwfm3ug8]

@WebKit #2 几个月前试过，Flutter 桌面版有的时候比 Electron 还慢

[duke807]

雙擊程序自動彈出系統瀏覽器呈現網頁界面，這樣既享受到 h5 的便利和快捷，又避免了 electron 的臃腫。
後台程序可以是 python 、go 等等不限。

[ysc3839]

C++ 搭配 React Native?

[ysc3839]

@duke807 说 Electron 臃肿不仅仅是说占用存储空间大吧？内存占用也大、性能也不好，这些是用浏览器也无法解决的。

[u823tg]

maui

[kilasuelika]

@duke807 Electron 那些不就是嵌入了浏览器，比较慢嘛。我自己感觉网页应用的响应速度肯定比不上原生。

[darklights]

占用资源小&好看&稳定&反应快 -> 显然 C++，没有之一。当然开发效率就是另一回事了。

条件反射般推荐 Flutter 写桌面程序的，我赌 5 毛，连搭个环境写 Hello world 都没试过。

[duke807]

@ysc3839 我沒用過 electron ，聽說每個 electron 程序都打包了一個瀏覽器，你安裝幾個 electron 程序就等於重複安裝了多個瀏覽器，因為是不同的瀏覽器程序，所以內存也不是共享的，這才是 electron 佔存儲空間和內存的根本原因。

而只調用系統瀏覽器，相當於瀏覽器增加了一個 table ，可以只增加很少內存佔用。

（關於 qt ，我曾經在嵌入式系統，使用 qtwebkit 還是 qtwebengine 記不清了，寫了一個極簡瀏覽器，它只負責打開一個本地 URL 呈現界面。好處是系統上電後全屏運行我的 h5 程序，不需要運行桌面環境。）

[duke807]

@ysc3839 內存問題我 11 樓有提到，
性能方面大多數場合也夠用。
專業領域，還是 C/C++ 比較快，譬如開源跨平台的畫 pcb 的 kicad ，用的是 wxWidgets 圖形庫，口碑比 qt 好不少。

[3dwelcome]

macOS 能用 C++直接写界面？

感觉不能吧。不都是用 obj-c 或者是 Swift 开发的。

微软已经放弃 C++的界面库了，全面推用 C#的 WinForm 。C++写算法可以，写界面估计不先包装个几层，还是很难写好的。

话说我在用 Electron 写桌面程序，开发体验感觉是真的好，也可能我本身就是前端缘故，如鱼得水，2333 。

[duke807]

@3dwelcome
用完全開源的 wxWidgets 可以使用 c++ 寫出跨平台且原生界面的 gui 程序，可以看一下 kicad 6.x 的各平台截圖，或者下載感受一下界面。當然也可以使用 C# 和 python 寫 wxWidgets 程序。
而且 wxWidgets 的版權也比 qt 好很多，qt 越来越不行了。

[rv54ntjwfm3ug8]

@duke807 #14 wxWidgets 有什么 UI 好看的开源软件例子吗？加过渡动画方便吗？

[duke807]

qt 的 qml 本質上和 html 差不多，用 qml 還不如用 html

[duke807]

@theklf4 我有提到 kicad ，涉及 2d GPU 加速，涉及 pcb 3d 展示和渲染，至於動畫，你可以看 wxWidgets 的動畫示範，應該比較友好。

kicad 是開源免費的軟件，你可以下載體驗一下。

[XCFOX]

来点新鲜的玩具：

Compose Multiplatform:
https://www.jetbrains.com/zh-cn/lp/compose-mpp/

React Native:
https://microsoft.github.io/react-native-windows/
https://github.com/nodegui/react-nodegui
https://github.com/infinitered/reactotron

Rust:
https://tauri.studio/
https://slint-ui.com/

如果是真的生产级应用还是用点稳定的技术。
写过 C# 再去写 C++ 简直是折磨吧。
目前 C# 比较稳定的桌面框架也就：
https://platform.uno/
https://avaloniaui.net/
坑多不多我自己也没用过也不清楚。不过话说哪个框架没坑呢？办法总部困难多。

[3dwelcome]

最近看了一个 C++工程（ https://github.com/filecxx/FileCentipede ），就是用自定义 sml 配置语言作为界面 UI 库，类似 flutter 那种嵌套式 UI 声明语法。

我个人觉得嘛，就算 C++工程，也还是应该把界面部分独立出去。尽可能把界面逻辑和程序逻辑分离，要不然代码会很乱，非常不好移植。

QT 和 wxWidgets 的语法，都是语言强关联的，这样并太好。你对比一下前端的模板式界面编程，都是必须先编译的，把界面模板编译后得到双向绑定的界面代码，控制起来要灵活很多。

[3dwelcome]

打错字了，应该是"QT 和 wxWidgets 的语法，都是语言强关联的，这样并不太好。"

C++里 UI 写复杂后，代码也是一大堆。要不就抽象出去，要不就用直接用配置脚本来驱动。但是这样的话，也相当于搭建了一个简易的 DSL(domain specific language)。

所以从我个人角度来看，UI 应该是不限语言的。

[aoeui]

可以等 MAUI ？微软官方的，应该比较稳定

[duke807]

@3dwelcome
我覺得對性能要求不高的還是直接用 html5 最方便。

對性能要求高的，可以 wxWidgets 內置 webview 負責性能不高的模塊，可以跑 js ，對性能要求高的部分用傳統的方式。
而且傳統方式也有界面 designer 工具，可以生成代碼。

[3dwelcome]

@duke807 "而且 wxWidgets 的版權也比 qt 好很多，qt 越来越不行了。"

QT 的学习资源多。大厂 QT 就和前端里 React 地位一样，团队作战肯定优先选择最主流的框架。

除非是一个人开发，进度不紧不慢，可以让你慢慢学。

[3dwelcome]

@duke807 楼主说了，不喜欢 webview 吧。

但我还是忍不住替浏览器说一句，WASM 是真喵的快。JS 代码比 C++慢，但 WASM 真的不比 C++慢多少，贼快。

[duke807]

@3dwelcome
wxWidgets 真的不弱，也很老牌，我以前沒把它當回事，一直覺得 qt 才是 no.1 ，後來也是通過 kicad 才知道 wxWidgets 比 qt 好，kicad 現在算是電子行業的主流軟件了，除了是極客和開源社區的唯一選擇之外，企業用戶也在大規模使用。

與之對比的是用 qt 寫的 eagle 畫板軟件，用戶基本上都轉用 kicad 了。

瀏覽器如果界面交互用 wasm 做，那麼也就享受不到 h5 做界面的好處了，wasm 一般不是拿來做界面交互的，頂多做一些波形之類的展示。

[3dwelcome]

@duke807 我上面说过了，不是说 wxWidgets 功能不好，而是 wx 和 C++语言联系太密切了。

这样的话，就很不好把界面部分作为独立模块，给完全独立出去。也就是我说的，最好的开发界面方式，应该是 filecxx 那种 sml ，用 DSL 来写。QT 至少有 qml ，不说功能对比，单从后期代码维护上，QT 是优于 WX 的。

其实 2022 年了，语言混编才是王道。死磕一种语言，真没什么前途。

[3dwelcome]

@duke807

"瀏覽器如果界面交互用 wasm 做，那麼也就享受不到 h5 做界面的好處了"

我在 wasm 里内嵌 React 之类的 JSX 来声明界面，代码需要编译后才能用，我自己都觉得挺奇葩。

反正代码能运行就行了，管那么多。

[duke807]

qt 寫的 eagle 也曾風光一時，落寞的原因主要因為它不是開源軟件，它只是受限免費的跨平台軟件。
不過 qt 不是原生圖形控件，這一點也不如 wxWidgets 。

@3dwelcome 傳統 gui 也是可以把界面做為獨立模塊的，譬如寫一個獨立的控件，整體 gui 也是可以獨立的，你自己做好區分就可以，有些代碼只負責前台，有些代碼只負責後台，明確前後台的通訊管道。

而且，我覺得 qml 這種的效率和 html 差不多，為何不直接用 html ，不用重複學習，調試還方便。做好的 html 可以用多種途徑呈現。

[wdhwg001]

flutter 的 win 桌面连个 cleartype 支持都没，真的还是别考虑了。

一定要成熟稳定的原生跨平台的话，或许可以跳出来试一下比较传统的 lazarus 。

[3dwelcome]

@duke807 "為何不直接用 html ，不用重複學習，調試還方便。"

CSS 太复杂了，需要套一层 webview 才能用。好一点的 webview ，体积都不小，这是楼主考虑的最大问题。

"傳統 gui 也是可以把界面做為獨立模塊的", 这点要在软件一开始设计的时候，就考虑清楚。我真不觉得你能把一个和 wxwidget 强关联的软件，把 wx 整个剥离出去。wx 使用方便的代价，就是强入侵性。

有人喜欢这种，我是不喜欢的。我喜欢每个模块都能随便替换，比如游戏开发，你 DirectX, OpenGL 都是可以随便换的。

[agagega]

Xamarin 也可以支持 Mac 的。你可以找找看这些不同技术对应的代表性软件，用一下就有感受了

[neoblackcap]

C#跟 C++不是对立的，完全可以用 C#写界面，然后调用 C++。C#调用 C++的库还算好调用。
然后跨平台，C#也有一些界面库，但是好不用就难说。
Qt 在这方面无论是稳定还是界面的好看，都相当出色。哪怕协议也是有 LGPL 让你选。开发商用软件都没问题。

其实还有第三条路，那么就是你自己写一个。使用一些图形库，直接写界面库，效率贼高，而且可以随便迁移（只需要写一个 render adapter ，基于 IMGUI ，帧数还能上升到 60fps 以上)，这方面的例子就是 sublime text

[lisongeee]

如果比较在乎打包大小可以用 Tauri ，宿主环境是 rust ，调用的系统 webview ，当然就得考虑 webview 兼容性和平台差异了

[exploreexe]

现在想想，web 技术果然是牛逼，真正的实现了跨平台。
你要想在 Mac 上流畅，按照苹果的尿性还是得上原生。Electron 这玩意开发的东西，我个人感觉能用，但是谈不上好用。

[janxin]

考虑你提到了稳定流畅，目前的跨平台方案都多少有点问题

wxWidgets 到目前为止都不支持 Apple Silicon...

[daokedao]

启动快只能是 C++
C# 启动速度比 Electron 还慢吧？

[leyviw]

cef

[nonduality]

别的不说，支持 OP 不使用 Electron 。Electron 就是一毒瘤。

[charlie21]

这选择这其实是一种捕食行为，又想吃得好 又想便宜 还怕吃坏了闹肚子。可能只有真正的试吃员能给你答案

[cmdOptionKana]

要用户体验好，前提是把东西做出来，用户才能体验。用 Electron ，提问的时间里 demo 已经跑起来了。不用 Electron ，我甚至怀疑你最终会选择放弃项目。

而且，Electron 还能让 Linux 用户受惠，没有 Electron 的时候 Linux 用户直接被忽略不计。

[mineralsalt]

现在电脑里面 Electron 程序的数量越来越多了, 虽然我不愿意用, 但是没办法啊

[0o0O0o0O0o]

我喜欢 electron ，没有 electron ，有些工具可能不会考虑桌面版

[leyviw]

cef + c++，ui 用 web 技术，核心用 c++，cef 比 electron 更简洁独立

[pengtdyd]

electron ，flutter ，原生这个三个我要选，我选 electron ，原因如下：
1.futter desktop 目前尚不成熟，需要自己写插件，有些功能不完善
2.原生虽然效率，速度，占用都不错，但是现在的个人 pc 早已不太需要考虑这些问题，从产品的角度来说，速度快永远不是第一考虑的事项
3.electron 经过这么多年的发展，nodejs 的生态已经可以覆盖几乎所有的场景，想用直接调用别人写好的包就好，开发效率高
4.electron 可以很好的贴合前端技术栈，这一点仁者见仁智者见智，至少对于企业来说，选择统一技术栈，更有利于团队的技术发展

[WebKit]

@wdhwg001 flutter 只是 UI 原生功能需要插件支持。

[WebKit]

@theklf4 flutter 的 debug 版本，会比 release 版本慢很多，因为它是热更新的，全平台都这样。对 win 的正式支持是上个月。以前都是 beta 。可以现在打包一个 release 版本看看

[ZSeptember]

QT 资源占用真不少，自家的 QtCreator Qt 写的，很慢。
看起来你还是想用 C# 的，那就看看 MS 官方的跨平台框架吧，我记得有好几个，Xamarin ，MAUI

我自己的话，没有 C# 背景，如果自己的应用，会选择 flutter

[secondwtq]

WASM 在 #24 还是不可避免地出场了 hhh

[macha]

先用 electron 撸出原型。
大部分应用对 UI 的性能要求没那么高。
没有完美的框架。

[secondwtq]

@duke807
为什么不用 HTML 用 QML：这个锅其实 Web 要背一半，HTML 背另一半。Web 的设计是在沙盒里运行，所有的 API 都要包一层，这就是说在 Web 平台上是无法直接访问到 native 上的 API 的。经过 Web 封装的 API 开销更高，功能更落后，基本上只有个下限。前两年前端各种“前端也可以 XXX 了”，实际上这些在前端之外的领域都不算什么。当然如果不在浏览器里跑可以自己做 binding ，但是还是比 native 麻烦。HTML 的锅是它本来是用来做文档的（“Hypertext”），不适合直接用来做“Application”，现在能做是后来各种补丁整出来的。QML 很明确一开始就是做 application 的。

另外你在个别行业看到的现象，需要个别去分析。技术对更大的东西的直接影响力很有限。实际问题要考虑更多技术之外的东西。
比如我在 VFX 行业看到的现象就是以前每个软件都有一套自己的插件开发技术，但是逐渐统一到了 Python+Qt 的组合。我能因此推导出 Qt 南波湾么？
但同时发生的另一个现象是 Blender 迅速崛起，彻底火出开源圈。就连现在 PC 硬件评测，以前跑 CINEBENCH ，现在也要跑 Blender Benchmark 。Blender 用的不是 Qt ，它自己写了一套界面库。能不能说他这个界面库比 Qt 更好呢？大概也不能。Blender 里面照样一堆老旧设计和屎山代码，它能火就是因为它开源，并且 somehow 一直运营的很不错，后来基本上除了已有专有套件的开发者和其死忠粉之外，所有人都认识到这东西能有好处，所以它花了十五年从默默无闻最后混成了 CG 圈的 Linux 。
IM 是另一个例子，小而美是技术最好的 IM 么？大概不是，但是在个别地区它确实是最流行的 IM 。

[nicevar]

这种没什么好的选择，跨平台 Qt 就是最好的，功能简单的用 Electron 做还行，复杂的就不要用了，Flutter 现在也就是个半成品，做小工具还行，做项目就是跳坑。

我试验过很多的技术选择，以前用 delphi/vb/vc+mfc/java+awt/swing/swt ，后面用过 Lazarus+Pascal/Codeblocks+wxWidgets/javaFx ，我就想说框架就选择最成熟的，否则那不叫开发，那叫踩坑，项目开发到一半发现有些问题无法解决然后推翻重来？这种公司我真的见很多了。

[MakHoCheung]

1. 会 C# 不会 Swift 的话可以上 MAUI （ Xamarin ）
2. 两个都会的话直接 WPF + SwiftUI ，SwiftUI 开发非常快的

[geekvcn]

大公司传统软件基本都选择了 QT 开发，AMD ，金山等。互联网公司基本选择 Electron 或者其他 webview 框架

[wdhwg001]

@WebKit https://github.com/flutter/flutter/issues/63043
别洗了，Flutter 桌面在 Win 端远远不止是需要写插件——它甚至连基础的文字渲染都做不好。

[wangyzj]

@darklights #10 +1

[wangyzj]

你看各自应用市场就知道
还有就是绝大多数游戏不支持 mac
所以桌面跨平台貌似只有 Electron 是个好选择

[luchong]

C# 直接 WPF 或者 Xamarin 吧 丝滑 爽的一批 好看又能打

[roundgis]

cross platform ui 都是要自己踩坑的

[g00001]

macOS + Linux 的桌面市场份额小于过气的 Win8 。跨平台带来的回报不大，代价却很大，专有平台的优势与很多系统自带组件都不能利用起来。

而且 “桌面软件”是一个很大的概念，具体到是什么桌面软件适合的开发工具都不一样，像用 C# 开发的桌面软件，往 ILSpy 里一拖源码就可以导出来，这要有心理准备。现在 Electron 也是被滥用得太狠了，网页套壳的程序，那确实 Electron 、WebView2 这些都没问题。但是有很多软件并不一定适合用 Electron 之类开发，像录屏软件 Gif123 下载体积只有 720KB ，输入法工具 WubiLex 下载体积只有 960KB ，这种软件用 Electron 就只会增加体积但并不能消减开发成本。

不过如果喜欢在界面上弄很多动画，这最好还是用网页套壳，Electron 其实也过气了，在 Windows 上更好的替代是 WebView2 。

[lonewolfakela]

整个邪道点儿的，用 Dear ImGui 整一个吧……

[nieyujiang]

我司已经打算换掉 electron 了。天天被用户投诉内存占用。和下载慢的问题。摊手.webp

[FrankHB]

挺尬的，半斤八两，尬的意义不一样……
如果你要开发体验的话，那么原则上是 C#，毕竟 Qt 你想用舒服基础姿势水平不低……C#的应用效果其实吃亏，但强在你能用更短的时间折腾出更多不同的方案试错。当然，前提是能实现。
.NET 在框架的意义上吹亏的就是定制起来没 Qt 那么容易折腾（或者说 Windows 以外基本就没稳定实现能用），Avalonia 这种比较新的，具体坑有多少没试过不好说。
Qt 虽然开发效率是个槽点，但是还有 Python 绑定能用（好歹没那么啰嗦），所以也算不上决定性的缺陷（用不用得惯 py 就另说了）。
如果你说做商业项目，要考虑让人接手，那么还是 Qt 忍忍吧。个人项目就随便了。
用不用 QML 看口味。我是不想用，主要是不喜欢各种 ML 那套（有这功夫还不如折腾 SGML+DSSSL 去了）。

Flutter 响应慢和资源占用糟烂是预料之中的，毕竟底层的开发者自己都缺根筋： https://github.com/dart-lang/language/issues/490 。
这类方案的开发者看上去的共同点是没有一个严肃的桌面客户端应用开发背景，整个技术栈的根本设计上就不用指望能解决此类问题，只能“优化”变通。
JS/Electron 之类的软肋也就是这个，而 Dart/Flutter 么，怎么说也不用指望有更好的资源来（各种意义上的）优化了。
大多数玩具也有类似的问题。Rust 实现的算是少数的例外，问题是 Rust 的这类项目都没多少存在感也活不大长，怕是所有第三方方案中最不靠谱的那类，支持就更加看脸了。

@duke807 wx 基本就是个跨平台 MFC ，除了用纯 C++而不需要 Qt 这种 moc 以及性能稍微（在 C++的意义上）更好以外，没什么技术上的优势。工具和开发者社区更不用指望了。
我见过有长期维护的项目从 wx 切换到 Qt 的，比如 TortoiseHg 早期用的 wxPy 后来就切成 pyQt 了。
虽然开发应用未必需要很在意，wx 这类“原生”方案有个致命的架构扩展性弱点：不是所谓的 direct UI 。（依赖 Win32 的 MFC 和 WinForms 也有类似问题，但大部分正常的都没有。）
参考 https://v2ex.com/t/831456#r_11329552 。

@neoblackcap 自己写一个当然是终极方案，不过就只是自己的项目用，太浪费了。
我就糊过能跨 NDS 和 Win32 的，上边 C++能做到都完全看不出是什么平台的（反正比 QtWidgets/QPA 那坨彻底得多），不过自己糊的开发体验嘛……mac 工作量不好估计，反正 Linux 的后端我是坑快十周年了。
imgui 这种 immediate mode 的半残基本也就算图形库了，都不算正经 GUI 库（撑死就是“画界面”外加输入套皮），GUI metaphor 基本都没在 API 体现，要在严肃项目里用还不如自己造轮子。
比起上面说过 wx 是缺乏可扩展性，imgui 这种就差不多没什么架构能被扩展。要从里面拆代码复用，那还不如自己照搬目的纯粹一点的图形库（ Cairo 、skia 之类）自己从头搭框架。

@ZSeptember 说 Qt 资源占用多，对也不对。
比起大多数其它 C++方案 Qt 往往因为不必要的运行时元数据访问而确实经常更拉胯，但一般同等经验的开发者写起来不会比用 C#实现的更慢。也就 QtCreator 这样规模的应用比较容易暴露出瓶颈。
更重要的是这里可是把 Electron 都拉上场一起遛了，正经写想更慢实在不大容易。

@wdhwg001 这只是相对其它成熟方案来说的，如果是相对自己糊界面库，这类问题就算不了什么问题，毕竟自己实现也得把这种东西折腾对，还是挺花资源的。
根本让 Flutter 无可救药的是上面说过的 Dart 的思路（同时也适用于 Electron ）。

[nicebird]

肯定 C++啊，看看经典的软件都什么开发的就知道。

[duke807]

@FrankHB 你說的 wxWidgets 缺陷我不太了解，貌似是 windows 系統本身的問題。據我所知，wx 是通過不同的適配層支持不同的系統，等需要時候再給 windows 增加一個現代化一點的適配層應該就可以了，並不是 wx 本身的架構有問題。
至於 TortoiseHg ，我看了一下，大概知道是什麼樣的作者和用戶群。深入融入開源世界的人，基本是不會使用第三方圖形 git 工具的，git 自帶的 gitk 就夠用了。
開源界的軟件都是 linux 優先，其它系統的體驗肯定要稍微差一點，kicad 這麼重量級的軟件在 windows 和 mac 下的表現已經非常好，所以用 wx 應該沒有什麼問題。

[FrankHB]

@duke807 抛开具体项目的选型来讲，你的一部分观点值得我单独点名反对。

（才不是看漏了呢，哼、、、）

如 v2ex.com/t/831456#r_11329552 分析的，所谓“原生”基本只是包袱，而不会是普遍意义上的优势。
首先，没什么最终用户就纠结真的 bug-to-bug compat 程度的“原生”。至少 GUI 用户是感知不到一个动作的响应是不是用 WM_SH*T 还是 signal 还是 std::function 来实现的。
所以，只要实现得了用户不需要分出差异的效果，这里的差别基本就只是对开发者有意义。但这个意义仍然是决定性的，存在高下之分。
根本上，就软件工程的一般方法论来看，实现用户需求的过程的正常方向是自顶向下的：了解主要需求，分解需求然后确定实现方案。
这个意义上，任何软件理想情况下理应都是所谓的跨平台软件，因为凭空依赖平台并不是一般用户的主要需求（用户只是“有啥用啥”而已）。这也跟这里分析的任何 GUI 都天然是所谓的 direct UI 一样。
只有为了照顾可实现性，开发者便宜行事，才添加实现细节而形成路径依赖，导致潜在的方案切换成本。这本质上是一种妥协，是一种 artefact 而不是 intent 。
是否使用所谓原生或者所谓的 HWND 都是这类细节的例子。把这种实现细节泄露到上层的方案中造成混乱的状况乃至坑到开发者自己，是到底，全体开发者的无能或者说失职。
具体来讲，现在需要纠结这方面的选型，直接原因就是 GUI 历史上的实现就很碎片化，导致能产品化的方案也很碎片化；而后来的开发者并没有能力把不同的方案统合起来（加上像 mac 阵营和早年 Windows 开发者都很多刻意搞封闭制造技术兼容性壁垒的），事实上根本没一般意义上跨平台的方案能用（ Web 也跨不了资源受限的一些嵌入式设备），所以才不得不去对照具体方案比较优劣计较得失（因为做不到面面俱到）。
想比较彻底地解决这种问题，专业搞 GUI 框架的都搞不定，作为应用开发者自然更加搞不定，这情有可原；但是不正面认识到这只是一种妥协，反过来以退为进，给碎片化继续火上浇油，不说技术上是否绝对正确，那起码算是个自私的方向。

@g00001 这里有个和上面相关的我需要批判的观点。
既然“桌面软件”这么个大概念的实现方案混乱如此，都快要指望全人类命运共同体都不见得能收拾得好了，那么纠结“一拖源码就可以导出来”就不应该强调。
或者说，为了实现刻意藏源码这种不是来自用户而是开发者自己的需求，增加另一个维度上的问题复杂度，这是唯恐天下不乱。
倒并不是说混淆源码的需求就一定是错的。而是说，即便藏起来源码开发者天然有权自决，实现成什么样的效果也是开发者自己负责，但一旦开发者行使这种权利，道义上就有必要需要理解这算得上是在薅市场羊毛，耗费本来就捉急的能系统性解决这类历史问题的公共开发资源。
这方面更应该鼓励的是把商业价值和源代码的可见性脱钩：在商业模式上做到即便随便让人扒源码也不会泄露商业秘密和损害销售，而不是道高一尺魔高一丈搞这种老实的最终用户只会凭空付出开销的军备竞赛。这样对谁都好。
如果能收拾好跨平台弱鸡可移植困难的局面，份额多少也会成为大多数开发者不用再操心的历史问题。

顺带说一下另一个问题：安装包体积和开发体积完全是两码事。安装包大是因为二进制依赖，这些依赖不需要应用开发者修改。而且只要系统自带就看不出来了。这个方面至少.NET 其实相当大，并不比 Electron 省地方。

[KoMAsS121]

@g00001 商业软件，公司写的加壳就是了（公司总不会像 VMP 的钱都出不起吧），不加壳，C++写的，别人也能一样分析呢。

[KoMAsS121]

@daokedao C#可以搞 AOT 的，像完全走 AOT 的 UWP ，他启动速度可真不差

[Hanggi]

vs code 启动慢？ vs code 优化好？

楼主怕是对用户体验有什么误解？

[jjx]

c# 要性能 自然, windows forms , 而且只用系统的组件, 至于什么 wpf ,winui 的,难

第三方组件不能用, 如 devexpress 之类, 性能杀手

而且以前用机械硬盘时, c#/clr 这种东西因为加载东西太多, 速度快不起来, 现在都用 ssd 的, 就没有问题


用 html 又要性能,自然是使用 sciter, 国内有个 miniblink 也可参考

[FrankHB]

@duke807 臆造“开源世界”把用户群体割裂是你的另一个明显的技术错误。
开源世界从来都不会整体认为 GUI 不重要。也没有显著的个体支持这种调调，相反的倒有不少。例如，Linus Torvalds 显然算是你所谓开源世界的一员；你可以参照一下他是否认为 GUI 的缺失对开源世界产品的用户更友好。
所以是否来自开源世界，用户对 GUI 的需求很大程度是共通的。要有差别也只是行业习惯上的问题（许多逻辑用 GUI 只会降低效率）；我举例的不属此例。

另一方面，你的说法暴露出你对你所说问题的很大程度的不熟悉。
首先一个事实错误就是 TortoiseHg 并不是所谓的“第三方 gui”，而是 Windows 上默认官方图形客户端。它很早（十多年前）就是随着 Mercurial 官方源一起提供下载的，甚至基本同时发布，只是早年版本号不统一罢了。这和 git/gitk 没本质差异，无非是 gitk 简单到之后直接整合到 git 的 repo 的子目录下一起管理了。
第二，你没看到不同 GUI 的差异。即使是同类的 GUI ，hg 和 git 差异也不小。不管是不是开源世界的，用过不同 DVCS 的用户，不少都认为 git 功能强大，但是命令行设计糟烂。有的用户会自己写脚本包装命令，而 GUI 就是另一种对更多新手用户解脱的方向。（虽说 hg 也有 amend 和 graft 都得 log --debug 才能看的笑话，但总体还是比 git 那么让人火大。）
遗憾的是，不少其它 GUI 也设计得很初级（特别是 git ，命令行的功能多得多，GUI 很多都没实现）。而同样叫做 Tortoise ，TortoiseHg 的 workbench 就吊打 TortoiseSVN 和 TortoiseGit （基本就只是复用了 troitoise 系的图标），功能覆盖度相对也很高，根本就不是一个档次上的产品。抛开 stash/mq 这种底层机制，像 diff/patch/shelves 编辑上的体验就不是一个等级上的，这完全是 GUI 自己设计的差异。
（ Atlanssian 的 SourceTree 就照搬了不少设计，和 TortoiseHg 主界面布局相差远不如 TortoiseHg 和 TortoiseGit/TortoiseSVN 差得多。）
至于 gitk ，说白了主要就只是 git log 的 wrapper ，就别提了。真要说的话，界面布局倒是也更接近 TortoiseHg 而不是 TortoiseGit 。

当然，这里的问题和 wx 还没太直接的关系。上面提过，这个问题是关于框架自身的，二次开发框架才会集中体现出来（死活都没法把 WinForms 改成 WPF 一样的无力）。应用开发者用 Qt 代替 wx 也经常有其它更显著的理由，比如工具和社区支持。

[FrankHB]

@FrankHB typo：但总体还是比 git 那么让人火大→但总体还是比不上 git 那么让人火大
（ git 让人火大的不只是 CLI 设计，至少还有在一些小版本瞎改文件布局之类。）

[anyele]

C#的 WinForm

[duke807]

@FrankHB 我可沒說圖形界面不重要，相反我覺得圖形很重要，gitk 就是圖形界面的，無論是我日常使用 git 還是給小白培訓都嚴重依賴 gitk 圖形。

同時我也反對妖魔化命令行，我認為命令行方便的就用命令行，圖形方便的就用圖形。我寫代碼會用 eclipse 之類的 gui 程序，覺得用 vim emacs 寫代碼的人魔征了。

對於 git ，我一直認為，精通 git 可以提升工作效率，而只會一點皮毛反而降低工作效率，而且總有一天會搞出飛機坑死自己。既然精通 git ，自然使用 git 命令操作 git ，配合 gitk 觀察狀態是最優的方式。

[tairan2006]

跨平台的话 Qt ，或者 Lazarus

不跨平台就 C#

[g00001]

@FrankHB 我是说了 C# 一拖源码就可以导出来，但应当没有 “纠结” 这事，源码一拖就出来多好的事！放心没有人想“刻意藏源码”，虽然现在不开源的桌面软件数量远远多于开源软件，但就像你说的人类命运共同体什么的 …… 就这样。

@KoMAsS121 赞同你说的没错，公司不缺钱可以用 C++ 开发，可以用汇编语言开发，不差钱任何问题都不是问题，C# 一拖源码就可以导出来只要有钱就不算缺点，正确得无懈可击。不差钱都没空上网争论哪个语言好。

[linghtls]

好看是指有配套的 ui 库吗…

[agagega]

@secondwtq
WASM 有啥问题么？

[FrankHB]

@g00001 不好意思，我看到的大多数用户提到这个“特性”时都是持反对的立场，所以可能误解了你的原意。
不过，考虑到拖出源码虽然自己看问题不大，拿来改其实就有一些法律风险，相对明确开源也不算很应当被鼓励。

[g00001]

有些作者可能事先并不知道这事。
前些天还看到有人说用 C# 写的软件写完了才知道别人可以轻松导出源码(包含工程文件),
有一个方法可以试试，用 aardio + C# 开发，操作简单不用花钱，可以阻止 ILSpy 还原代码，可以内存加载 C# 写的 DLL ，生成极小的独立 EXE 文件。

发个例子：


源代码；
import win.ui;
var winform = win.form(text="嵌入 .Net 控件")
winform.add(custom={cls="custom";left=25;top=25;right=736;bottom=274;db=1;dl=1;dr=1;dt=1;z=1})

import System.Data;
import System.Windows.Forms;
var Forms = System.Windows.Forms;

var dataGridView = Forms.CreateEmbed("DataGridView",winform.custom);
var dataTable = System.Data.DataTable("DT");

import System.Type;
dataTable.Columns.Add("名称");
dataTable.Columns.Add("计数",System.Type.GetType("System.Double"));
dataTable.Columns.Add("选择",System.Type.GetType("System.Boolean"));

//绑定数据源到视图
var dataView = System.Data.DataView(dataTable);
dataGridView.DataSource = dataView;
dataGridView.EditMode = 2;

//添加测试数据
var row = dataTable.NewRow();
row.ItemArray = {"王五",123, true}
dataTable.Rows.Add(row);

winform.show();
win.loopMessage();

[FrankHB]

@g00001 不差钱也可能不行，有的项目进度卡的可能某些方案就是神仙也没法及时开发出来，选型上只能各种抠了……

[FrankHB]

@g00001 你这方案看上去可能一些方面维护成本很可能会相当地高：www.cnblogs.com/yaoyue68/p/14327559.html

[bthulu]

为什么没人考虑用 java 呢, jetbrains 就是 java 一把梭, win, ios, linux 全支持

[shawnsh]

占用资源小&好看&稳定&反应快，不可能都达到，达到两个是现实

[g00001]

@FrankHB
呵呵，这么 low 的帖子居然能被你扒出来，那么不顺手扒一下别人怎么回复的吗？

Jacen
————————————————————————————————————
有一个现象无法解释，能学好其他编程语言的，学 aardio 都很快，
很多人告诉我几乎拿上手就会用，比任何编程语言都容易。

而说 aardio 难学的 —— 这些人几乎学不好任何编程语言，
做 aardio 这十几年我看到的喷 aardio 不好学，却能学好其他编程语言的 —— 我一个都没见到。

上次看到博客园的遥月长篇大论的喷 aardio ，然后还刷了几天 C# 的学习心得，其实我很期待他真的能学好一样其他的编程语言，但是一年过去了，他人间蒸发了，C#他学了十几年都没学会，可他就是愿意跪舔 C#。

如果 aardio 精心打磨了 17 年的教程你觉得还不方便让你入门。
如果 aardio 提供的系统而完善的使用手册、库函数手册 —— 你觉得不够容易。
如果 aardio 提供的大量篇幅短小的快速入门教程，从最简单的程序到一步步做出精美的界面，有图文，有视频，涉及到 aardio 的各个方面 —— 你又觉得不够系统。

那没有理由继续为难自己用 aardio 啊，为什么不换一个更好的呢？！更好的编程语言那么多。

如果你对编程教学、鉴别品评编程语言都很有心得，那为什么不对自己好一点，选一个好语言给自己？！

如果你对编程教学极有心得，那为什么不对自己好一点，把这些好的教学方式用到自己身上？！

不是不想改进，aardio 一直在努力倾听和前行，活跃更新了十几年。但是这些地图炮式的吐槽 —— 你自己都没办法用这些方法教好你自己，又怎么肯定用你的方式能教好其他更多的人？！

这是昨天一个用户发给我的感谢信：
------------------------------------------------
感谢 aardio 作者，我是刚开始用 aardio 写界面（实在不想用 pyqt 了），python 写数据处理业务，感受到了 aardio 的强大和奇妙。我想把 python 数据处理过程的信息反馈到前端界面中，《这回让我们把 Python 玩出花来》看完后，用了几分钟搞定！！！实在令人惊讶 aardio 的强大！！！再次感谢 aardio 作者的奉献！！！
------------------------------------------------

他才刚接触 aardio 几分钟而已，看了一个简单的教程就用 aardio 写出了自己想要的软件。
有不计其数的用户学不好其他编程语言，却学好了 aardio 。

luohexi
————————————————————————————————————
我是非专业的，疫情以来这两年就想做点文件处理的工具，主流软件都摸索了一遍，今天发现了 aardio ，学了一天就整出来了一个工具，正是我想要到效果。真是相见恨晚啦，太感谢作者大神了，中国人的思维太了不起了。功能强大而直观，不像所谓到那些主流语言弯弯绕太多。

[ragnaroks]

只考虑 windows 就 dotnet 这套，考虑 linux 就 QT ，别整其它花里胡哨的

[duke807]

@bthulu 用 java 不如用 python ，python 用途更廣。
java 寫的 gui 的界面經常卡死，曾經用 quartus 的 ip wizard ，現在用的 stm32cubemx 都是經常卡死，resize 窗口后，需要重新繪圖的區域變成白色。把 ibus 輸入法關掉可以避免界面卡死。

[g00001]

Google 一下 Python + aardio 的文章
https://www.google.com/search?q=python+aardio
不同的编程语言不一定非要互撕，也可以团结合作。

[timpaik]

@g00001 跨平台的话 aardio 就不太行了，题主要求跨 MacOS/Windows.....

[FrankHB]

@g00001 我没听说过（或者听说过忘了），随便百度了一下。
一般开发者倒不怎么首先会关心难不难学的问题，而是开发资料是不是容易找。
于是这社区建设看起来比较捉急。
或者至少 SEO 没做好，以至于直接搜就是那么 low 的评论。
而且看上去不是一个两个的问题，怕是快人人喊打了，也是蔚为奇观……
zhihu.com/question/39393984
像这个是不是更 low 。不过你都直接上镜了啊……
v2ex.com/t/249946#r_2808385
倒是理解为什么 SEO 上弃疗了。

[Cielsky]

试试 tauri ？虽然也是 web 吧，不过至少打包体积少了很多

[BigDogWang]

flutter 桌面版有个致命的缺陷。因为其引擎机制问题，导致桌面版不支持多窗口，很难受

[g00001]

@timpaik 你说的很对，这个主要是楼上那位转到额外的话题了。
跨平台有很多种，其实没有真正的完全跨平台，都是部分跨平台，还得生成不同平台的执行程序，开发中还是不得不面对各种专有平台的问题，在 Electron 群里就经常看到他们在纠结一些很初级的问题。

首先在事实上 macOS + Linux 的桌面市场份额小于过气的 Win8 。跨平台的方案通常会带来不必要的负担，像 Python 开发本来是很利索的，但因为有跨平台的负担，所以写桌面界面，不如 aardio 轻快。

如果考虑事实上的 “部分跨平台” ，将一些公共的代码做成组件，用 C++ 或 C# 写都可以，或者如果用 WebView2 这种网页套壳 —— 网页部分也可以做成公共组件。

那么如果说是这种部分跨平台的话，aardio 就非常方便了，aardio 可以调用十几种编程语言以及这些语言的组件，像 C# 组件 C# 函数，或者 C,C++ 函数这些都不用写中间代码，直接可以调，更不要说调网页有多方便了。

[FrankHB]

@duke807 你的确没直接说图形界面不重要，但是如果稍微多使用一点，就会发现即便只是日常使用，gitk 都相当不够用（再怎么说 gitk 也只是集中 log ，而 log 外各种各样的重要功能太多了。）所以如果真关心的话，一般很容易发现不足而比较过流行的同类产品，这样就更不应该发表那么轻率的观点（哪怕你只是把各个软件的主界面截图搜一下都能看出不少差别）。
不过你显然连 TortoiseHg 的官网都没找到或者仔细看，否则不会那么容易误认为“第三方”。所以我有理由怀疑你认为 GUI 至少在这里不太重要。

同时我也没妖魔化命令行。我只是说 git 的命令行尤其不好用（乃至于有用户自己包装命令行），GUI 只是新手的救星。同样是命令行，hg 就正常得多（虽然也有些问题）。
而且即便是 TortoiseHg 也不是完全覆盖了日用场景的命令，也需要命令行补充（其实 TortoiseHg 自带控制台能输入命令，但是我的系统上有其它包源安装的 hg ，我经常开终端混着用），特别是还有非官方插件。（我日常 push 就是基本在终端连续操作，因为 hg push OSDN+(hg-git) hg push GitHub 之后顺手还要 git push 到其它 git mirror ，还是全终端顺手。）

（我在其它地方有时候的确会“妖魔化”命令行，但一般是黑 shell 不够靠近“正常”的编程语言，是以 API 而非 UI 的角度来说的。作为 CLI ，黑命令行基本都是黑 cmd ，偶尔黑一下 ps1 。）

[nashaofu]

老哥可以看看这个呢？安装包体积很小，开发效率不错 https://github.com/tauri-apps/tauri
webview 实现方案

[g00001]

@FrankHB
觉得你很有趣，
说了一下 C# 写的软件可以导出源代码，你就上升到 “人类命运共同体” 吓我一跳。

提了一下国产的 aardio ，
你这就卖力地搜索 aardio 的所谓 “黑料”，
说实话我看得莫名其妙，你到底是想表达啥意思？！

你在知乎扒了这么久，不扒到别人在问为什么同是国产语言，aardio 在网上一直是好评居多？！这就是你所谓的“人人喊打了，蔚为奇观 ……” 是你的人类命运共同体这么跟你说的？！

[FrankHB]

@timpaik 直接切中要害所以我本来不想复读，不过这里关于 Aardio 还有个公共问题。

就跟我上面评论为什么 wx 不好（或者说不指望有什么好的未来）一样，一个主要问题是本身的结构导致可扩展困难，在二次开发集中体现的。
这导致的长期后果是继续保持市场上桌面 GUI 开发方案的碎片化，不够解决 OP 纠结的问题，还可能加剧恶化这种状况。

我找了下，Aardio 似乎就根本不提供核心实现的源代码。这就是更极端的问题了：根本不可能实现对核心进行二次开发。
如果开源，即便不提供官方支持，或许还有哪个第三方可能有兴趣移植（尽管可能跟.NET 一样过于依赖 Windows 而长期不成气候），还有资格在这个问题里作为候选；但没源码直接就是画地为牢，自绝于（专业）用户了。
即便库给源代码，但是 Aardio 又不是标准化的语言，市场占有没优势，也没什么超过 Python 之类其它流行语言独立开发的特色，有多少专业用户有兴趣贡献源代码？
所谓部分跨平台，你要 C/S 分开说还好，但看样子全是客户端的，有多少实际案例？ B/S 方面，相比 cef+前端全家桶，有什么优势？
面向非专业用户的低代码工具么，看例子实际代码量也不少。只是省掉中间代码，能吸引多少用户姑且蒙在鼓里。
所以除满足需求的能力存疑外，这个定位各种方向上都很迷。

[g00001]

Google 一下 Python + aardio 的文章有很多
https://www.google.com/search?q=python+aardio
谁喊打了？！你那个自称 Python 用户的遥月？！

知乎上尽挖坟挖到了那些没人关注的帖子？！
500 赞的介绍 aardio 的贴子你神奇地没找到？！
https://www.zhihu.com/question/453979660/answer/1841544999
这是你说的人人喊打吗？

又开始扯 aardio 不开源吗……
aardio 官网首页的回答这个问题的这篇文章你也选择性忽视了？！
https://mp.weixin.qq.com/s/VBV5px3IPrJR40kpEk5M-w

[FrankHB]

@g00001 作为桌面开发者，我对 OP 面临的半吊子开发方案到处都是的碎片化现状极其不满意。
不说 BS 应用，不说移动端，桌面 GUI 的整体需求应该足够明确了，市场够大，投入不小，为什么几十年来会整成这样？
“人类命运共同体”就是在黑整个业界各玩各的，谁也不服气谁，结果不说产品级方案够不够跨平台，就没整个像样的选型指导结论共识出来，搞得下游的开发者被迫站队跟着各玩各的。

原则上，你要提供一种新的方案当作选择没什么问题，但是没解决原有的问题还会有效添乱的话，那我自然不会有什么好话。
你所谓的好评，我自忖了一下，大概占据这个市场的比例不会多。当年我会按键精灵的小屁孩水平可不怎么有把握学会这一大坨，但是真会专业开发技能时，又发现这些东西完全不够看了。
而有希望成为 Aardio 目标用户的，如同上面我找到的第一个 low 的链接所说一样，可能真只有所谓的“熟手”（先不管别的方面说的是不是真的 low ），也就是退役的职业桌面开发者或者怀旧党。
具体问题很多，比如你支持 Aardio+Python ，表面降低门槛，但实际上新手连 Python 都不熟练，要同时掌握两套体系有那么容易？

另一方面就是严格的 GUI 开发本来就有隐含的门槛。
比如 GUI metaphor 和所谓控件的联系，比如事件循环，这种东西怎么明确通过 API 中的实体表现出来？讲不清楚这种道理，只是鼓吹什么样的显示效果和表面上怎么短的代码对应，是不可能简单到哪去的。（我黑 imgui 不算 GUI 库道理也类似。）
遗憾的是，我找了一圈没找到系统化描述这方面整体设计的相关内容（也可能是我没找到）。
即便是专业开发者，也得猜哪里要有等价的功能；要是能随便容忍这种缺陷，这就不只是专业 GUI 开发者，而是框架 hacker 了，自己有资源就一定能手糊出整个解决方案的那种。这种用户的忍耐是用在 Qt 这样的业界主流而不是 Aardio 这种小众方案上的。

再上纲上线一点，随便挑一个出来讲水都深得很。
比如事件循环，说白了是所有交互式程序（包括 REPL 和像样的 GUI 应用）的公共框架，作为 trampoline 是一类解释器的实现的 top-level ，也是 CESK 这样对应现代的形式语义的抽象机乃至当前物理 CPU 的顶层逻辑结构。所有这几样东西我都像模像样地自己独立实现或参与制造过，不是在工作中就是现役仍在日用的私货上，所以有第一手经验证明这不是理论废话。
基本上这些东西都有一些现实上的缺陷而让我不能满意。所以我对现状的不满其实已经收敛了许多，你觉得我有兴趣纠结区区一个局部的坑上，特意针对具体方案来形而上地黑嘛？

最后，你应该能看懂，我之前说了那么多，完全是站在鄙视区区一个桌面 GUI 都还要纠结跨平台的整个业界的专业用户立场上的。所以你觉得我是 Aardio 面向的用户群体嘛？

[jones2000]

这种就看预算， 和开发周期了。 要用户体验好，肯定是 c++用直接调用底层 GDI/GDI+绘图（ chrome 也是用 c++). 这种定制的 c++ 价格不便宜， 没有 8-9 年的 c++客户端开发经验也搞不出来的。

[duke807]

@g00001 看了一下你說的官方官網首頁的文章，表示被噁心到了。。。