小团队 Windows 桌面客户端程序用什么技术栈比较好？大家有什么建议

自己顶一下，现在是不是没人开发客户端软件了？

那就 Electon，多平台复用，也能直接上 web 。正好也为之后的小程序做技术积累

跨平台还是 Electon，不跨平台还是 net，

直接开发成 web 版，然后套个 Electron

Sciter 可以试试，JS 的，描述说打出来的包比 Electron 和 Qt 小很多。

熟悉哪个用哪个

最近.net 快发布了，加上 blazor 很火，心里痒痒。想迁移到到新的.net 5 平台，但是 blazor 好像没有官方的 UI 组件库，有点拿不定主意。

@jorneyr Sciter 更小众了吧？

@zhuangzhuang1988 团队技术 zhan 栈很老，想趁机升级下，有没有未来 5 年可延续的技术平台？

@JerryCha 也是这个意思

@renmu123 嗯，web 有前途

@annielong 现在.net 跨平台也行吧？

建议转 Web，客户端用 cefsharp 包装一下， 调用 Windows API 还是 csharp 方便

不考虑程序体积的话，还是用 Web 那一套吧，跨平台方便。

@MasterMonkey #8 Sciter 用的人少可能是因为商用要收费，在 Web 技术免费且生态丰富的情况下，优势并不明显。

桌面端跨平台的话我觉得意义不大，除非有明确的 macOS 和 Linux 的需求，纯桌面端怎么说都感觉是 WPF 最合适。当然 WPF 是严格限定在了纯 Windows 平台，.Net Core + WPF 最大的意义可能也就是复用一下 dll 。Xamarin 的话目前确实被 Google 的 Flutter 吊着打，之后又要被 MAUI 取代，至少不建议尝试 Xamarin 。

短期先快速迁移到 .NET 5 + WPF 然后苟着吧，后面会怎么样都不清楚。

@hjc4869 理解，这个暂时是行得通的。但是，忍不住想带点 Web 技术，Web 太强了

1

@WangLiCha 你说的对，Xamarin 感觉鸡肋的很，又要出 Maui 了，又是大重构，微软天天折腾。连个的控件库都没有，好歹提升下生产力。

又要 Maui，又要搞 MVU，Xamarin 又是大升级，感觉微软是财大气粗，啥都想搞一下，结果呢，全是备胎技术。

我还是盯住 Asp.Net Blazor 技术吧，然后加个浏览器壳，这个技术，微软应该不汇乱折腾吧。不想用 WPF 了，开发人员很难招，Web 人才更多点。

但是呢，Web 有点乱，我们是传统的团队，业务导向型的，太 Web 的话，我们又搞不来。

如果未来会逐渐迁移的话，建议还是 Electon 。

@beginor 嗯，Windows 和 C#一直用，但是我想用 webview_sharp, 挺轻量级的

@wzzzx 除了壳，另一个头疼的组件库，web 选择好多，选择恐惧症来了！

@MasterMonkey cef 就是嵌入的 chrome 呀，我们已经在用了， 前端三大框架选一个就行

@beginor 请教下这个和.net single file 发布模型兼容不？

另外，我是想找一个轻量级的浏览器方案，直接用系统自带的，自己就不带了，太大。

还是 electron 吧，好招人，好迁移。。已经把 qt 和.Net 秒了

@gainsurier 理解，关键是公司里面 C#+WPF 大把工程师，换成纯 Web 的话，步子还是很大的。但是也明白，Web 绕不开，是终极解决方案。 所以微软 Blazor 这种 C#+HTML+CSS 的方案对我们还挺有吸引力的。

换个靠谱的 web 工程师很难的，现在很多也都仅仅只是会写页面而已

在大公司用 Qt，但仅限于 Windows 和 Linux，在 mac 上还是用 swift cocoa 写的

不是熟悉什么用什么么...

跨平台 electron, 不跨平台易语言 /滑稽

@edk24 易语言，没用过

新项目可以尝试下 Blazor 。
MAUI 替代的是 Xamarin.Form，这两都是基于 Xamarin，Xamarin 应该会合并到 .NET 6.0 中。
也可以看一下 Uno Platform，也是基于 Xamarin 开发的。

electron 足够了，没必要整太复杂

要用 electron 请考虑 miniblink 和 mini-electron, 10M 级

electron + quasar
quasar 一套代码能打包多个平台，封装的还不错，配合 electron 很快出成果

既然有 Python 的技术栈，当然是 PyQt 喽，也可以跨平台

微软确实喜欢瞎折腾，不知道什么毛病……绑定在它的技术栈上，不一定是好的选择。

electron 最快乐

Windows 上用 C++ MFC, 所有 UI 可以使用 GDI，GDI ＋，openGL 等绘制．
另外不能因为要多平台而使用一套代码，这样性能很差．　最好是采用代码移植的方法。

还是建议 WPF

Electron 这种垃圾玩意五年之后还在不在都不一定了

不要低估 node.js 那帮人的实力

（即使 五年后 Electron 还在，它也不是 2020 年的 Electron 了。

兼容性是什么？倒行逆施。反倒是 你一旦踏上 Electron 这种东西，你就得年年随着它的最新更新而推翻重写。这就是 js 界的阳谋，反正大家都不失业。年年重写嘛谁会失业，那肯定是不肯重写的要失业了

本该用 2022 年的 Electron 了，你还在用 2020 年的 Electron，你肯定失业
你 2018 年写的 Electron app 现在还能跑吗？

不过也不怪 node.js 那帮人，node.js 那帮人就没有考虑兼容性的资格

可是你 2010 年写的 WPF 软件在 2020 年还能跑.

只是 Windows 用.net 是最好的。

为什么没人担心自己会被替换掉呢？就是逐渐把你们替换掉：

只要开始写 Electron 了，写 Electron 的人就是要逐渐把你们写 WPF 的给替换掉。到时候余下的你们不得不陪着 node.js 那帮人年年学新招式，陪他们内卷。这叫引狼入室（ 彼时看公司人员构成，WPF 小团队已经被砍掉了，客户端都是写 Electron 的了 而且是年年追着最新版的 Electron ）

被替换的人 自然就担心，替换人的人 自然就不担心，那无知的孩子：她那时候还太年轻，不知道所有命运赠送的礼物，早已在暗中标好了价格。 你就是这价码的一部分，那分不清什么叫 优胜劣汰、引狼入室、良币驱逐劣币、劣币驱逐良币的人 就是这价码的一部分

maui
应该可以

要么向底层+高效迈进，转 QT C++。要么保持 .NET WPF 不动 。如果 PC 客户端很重、略卡。那做客户端的意义又在哪？

@jones2000 MFC 做 UI 程序生产力太低了吧，这个不好

@charlie21 嗯，同感，上了 js 的道，就必须天天升级了。

@charlie21 啥，太深奥？

@quan01994 这个不太靠谱吧，还在实验，一块大饼！感觉会被坑

@t6attack 客户端是业务需求了，用什么技术的话，主要是考虑好开发、好维护、方便和设计团队合作

@MasterMonkey #47
我也有这种感觉 MFC 是个老古董,没记错的话是直接调用 WinAPI 绘制控件之类的,UI 稍微复杂点就效率很低.

还是要看需求啊，你像 telegram 这种聊天的基本就是网络请求的，用 electron 就很适合。但要做那种工控的，一堆 native 调用的，用 WPF 就适合很多。如果是高性能要求的，例如实时视频直播的，WPF 都不行，只能上 C++。

我看了全部是回复，居然没有 delphi c++builder vb，我感到很神奇，认真做一套方案至少可以卖 30 年

@h82258652 #53
telegram 的 Windows 客户端用的并非 Electron.

用 python 和 node 写桌面应用亏能真的做出来，不追求点开发速度-性能-稳定性的平衡嘛。electron 难用到爆，资源占用不说，开发起来坑就慢慢踩吧，上几个月做个工控没累死，最后砍了，用 wpf 重做。原生的多好不说，.netcore 基本是最前列的高级语言了，还考虑别的跨平台属实没必要

最简单的难道不是。全平台切换到 Linux 。这样就不需要再考虑垃圾的 DotNet 了

推荐这个 Nodejs+Electon

你只需要招一个大佬把架子搭好，之后就是前端编程了，不愁招不到能干的人。

Electron 吧。。。虽然大

看需求，如果需求复杂又追求性能的用 Electron 就是往火坑里跳，你们都有资源为啥不选 WPF ？这不没事找虐么，至于你要迁移 Web/Mobile/小程序完全可以用其他方案，没必要把系统差异巨大的东西非要整成一套，结果做出个四不像。即使是 2020 了，那些大型长期使用的应用大多还是 C 、C++的，Electron 开发出来的大多是辅助类的。

@weiqk 我以为现在没人用了呢

@alonehat WPF 这个完全赞同，公司用了 10 年了，非常好。现在 Web 火，公司在转型，想留点余地，慢慢引入一些 Web 技术

@alonehat

>>.netcore 基本是最前列的高级语言了
这个赞同

@cassyfar 我们 Team 还没有 Web 前端的氛围，后端工程师为主，需要一些对后端友好的方案，想试下 Blazor

@nicevar 有资源，但是不富裕。整体团队比较大，我们能使用的资源不多。

@IsaacYoung 如果程序是一个 Web，直接嵌一个原生浏览器，用浏览器打开应该也可以，省去打包一个浏览器。

@MasterMonkey 推荐一个方案：
GTK + Vala，写法上和 WPF + C# 类似，原生的，控件组合非常灵活，只要你充满想象力，都可以实现目标；

Windows 的支持打包已实现：
https://datatable.online/zh/blog/002-how-to-deploy-gtk-app-on-windows.html

MacOS 的支持和打包已实现：
https://datatable.online/zh/blog/004-how-to-deploy-gtk-app-on-mac.html

有成功经验，不用自己摸索，我用这套技术栈已实现数据库工具，项目网站在这里：
https://datatable.online/zh/

如果有 win32 开发基础，当然 flutter，没有的话，什么都无所谓

马上.net 5 了，用 Blazor 就完事了，要注意的就是客户端 wasm 里跑的是解释方式运行的代码，性能拉跨，你可以测测看。

等.net 6 里 blazor 支持 aot 了才能解决。

如果对客户端性能要求不高，或者是能等到.net 6 发行，就没问题。

小团队建议考虑技术风险与成本。选择最成熟的。

我们一直用 C# winform ,后台逻辑 web 也可以复用； 下一步有些界面准备用 Edge WebView2 嵌套 web 试试

你这个技术栈 最好选 2

很显然 Electron 。

然后有很多人用之后有钱了选啥都行，用别的效率都被吊打，小团队先出货。

@andytao gtk 太情怀了吧，哈哈

@qdwang 性能不是第一优先级，主要是要好上手，好迭代，好发布，好维护，后端友好

@ebony0319 有一定的风险容忍度

@PopRain 我也想这样干，我试一试

@tairan2006 python 写界面，感觉不是很有信心

看具体项目需求吧，用 web 界面，是为了写 ui 轻松一点。
可有些传统客户端开发里，界面只占了很小一部分代码，大部分是功能性 cpp 代码，这就没必要迁移了。

@loginbygoogle 总感觉 flutter 会有一些不好解决的坑

@3dwelcome 我们这边一半一半

@andytao 去看了你的神作，确实不错

1

@wangyzj 看来 Web 人气是相当的高。现在的场景就是小马过河，看来我的自己试一试了

vue 什么的没搞过的话，估计还得踩踩坑。没有跨平台需求 wpf 不香吗？

当然是继续.NET ，最多.NET Framework 换成.NET Core，不过最好原封不动，有时间干点别的他不香吗？
再说要做 Web 或小程序的话，用 ASP.NET Core 起个 WebAPI，之前的一些.NET 代码也可以复用，何乐而不为？

@jeffw 我基本也是这个想法，还是聚焦在.NET 上面。

如果引入 Web，能提升下生产力的话也是不错的

@xuanbg 大概率将来会跨平台

Win32 我最喜欢的还是 WTL

@xxzs 那你肯定很老派，我只想搞定需求、搞定设计、搞定开发早点下班，哈哈哈。

项目技术选型，首先要根据需求来选。

你需求都不说，上面那些老哥却一个劲地推荐各种方案，我也是看笑了。

桌面推荐 sciter，移动推荐 flutter，至少我的项目 https://github.com/rustdesk/rustdesk 选型是这样的

windows 第一选择是 dotnet(WPF/Avalon),第二选择是 c/c++(MFC/QT...)

其他都是二的选择

@opentrade 你是又一个推荐 sciter,我去查查

@MasterMonkey 大概看了下，思路很好。照这个思路，在 dotnet 也行的，我们团队 dotnet 积累比较多

只有 Windows 个人比较推荐 .NET 平台，不是很推荐 QT，一方面上手难度大，另一个 QT 定制起来比较累，很多东西做起来并不方便。

跨 Web 也许可以考虑 Flutter ？不负责任的推荐…现在 Flutter 应该是可以跨 Web Linux Windows 和 Mac 的，但很细节和具体的我了解不多，所以不做过多推荐

@crayygy 嗯，倾向.NET ，但是不想用 WPF 了，没啥生态。flutter 的话，我试了下，web 和桌面都支持，确实很酷，但是我感觉 flutter 在描述复杂界面时，易读性和可维护是个问题，类似用函数描述的方式整体描述界面。更喜欢 blazor 这种自由描述界面的方式。当然，新的技术，都是高度一体化，和设计团队的分工和协作再次成为问题。个人观点:)

@laminux29 兄台你的嘲讽我不完全赞同，技术和方案都会有一些时代特征的，也就是说免不了就那几个选择，一线的朋友提出几个比较好的来讲，说下自己的感受对我还是有帮助的。

QML 如何。。有一个专用的 platform Felgo

可以用 js 或者 c++扩展

@AndyAO #55
原来是我记错了，看了下 about，发现有 github 源码，还是 c++ 的。