如何看待 JetBrains 推出的轻量级编辑器 Fleet？ 第1页

学校说让我休学或者退学 原因是觉得领证结婚的学生不好管理 除非我去办离婚证 才能让我正常上学

题主说“学校说“，没具体写明是谁说，也没具体写明是哪个部门说，有可能就是某个办事的人说的。建议先沟通，至少要把学校里有话语权的人和部门都沟通到。

我举个例子：有个学生大二了想退学生会，学生会负责办理的人说：退会需要写一份不少于8000字的申请书（或者是其他什么刁难的条件），否则不允许退会。这个学生就觉得退会太难办了，每天发愁。

另一个同学也想退会，也遇到了同样的问题。但他没有发愁，反而觉得通过办这件事可以锻炼自己解决问题的能力。咱不惹事情，但事情找到自己头上了，躲就不是办法了。他挺高兴，有这么一个事情需要自己去办。如果连这点小事都办不了，以后走向社会遇到的难办的事情岂不更多嘛。于是他和和气气地离开了学生会办事人员那里，然后去找学生会会长沟通。

学生会会长出于维护自己手下办事人员权威的角度考虑，也让他按要求写8千字。

他和和气气地离开，去找辅导员了。路上他想着：辅导员办不成就找系里、院里……系里院里还办不成就找校方负责部门，比如校团委。再办不成就找负责部门的负责人、再办不成就去找学校纪委、党委，再办不成就找书记、校长……

他就像完成一份论文一样做着前期谋划，结果还没找到系里，辅导员就帮他协调着退会了，只写了几百字的退会申请。

回到题主的问题里来，学校里从下到上这多人和部门都算是“校方”吗？题主说“学校”让她休学，到底是学校里一个小办事员说的，还是从下到上都这么说？是不是底层办事人员懒政搞一刀切？是不是校方中层、高层都根本不知道此事？这些都要弄清楚啊。

题主可以逐层和校方沟通，估计沟通到某一层次就解决了。如果真的一直沟通到顶层的校长和书记也没搞定的话，那么才能真正视为：“学校让你休学”。

不要害怕和学校高层沟通，都让你休学了，没啥害羞和害怕的，对你来说这么大的事件，就算每天在校长办公室门口堵他，也得争取到和校长沟通的机会。也许这在校长眼里就不算个事儿，他给下面打个电话，你的烦恼就全都消失了。记得和各层次人员沟通时都要注意保留证据比如录音等。

沟通时要观察对方是什么样的人，如果是忠厚老实的，你就多多卖惨卖可怜；如果一看就是官僚气十足的话，可以用一点小手段，比如问他：“您真的没办法了吗？唉……咦？旁边办公室是不是领导的屋？我去找领导是不是能帮我？”如果一看对方就是欺软怕硬的，可以问他：“我实在没办法了，您说我可不可以求助媒体和记者？您再给帮我想个办法吧，对了，您说我打市长热线能解决吗？"。简单来说，小手段就是以低姿态让对方无法立刻翻脸的前提下表达出威胁对方的话语。当然，对于大学生来说，社会经验不足，也许无法识别出对方是什么性格的人，那么就按提前做的对话草稿，把想说的话统统说了，姿态要低，毕竟你是学生，对方代表学校。态度要好，不要发火，要把困难看成学习上的一道难题来慢慢解。

一般来说校方不会和你一个学生死磕到底的，此时学校就会让步。为啥会这么说，因为穿鞋的都怕光脚的，你都要被退学了，你怕啥，学校才怕你这种不稳定因素呢。（再送题主一个小手段吧，哭！女性哭起来很有杀伤力的，在校领导办公室哭！声音呜咽凄惨，越大越好，越有别人来找领导签字时越哭，门外越有人等的时候越要痛哭着离开，让大家四目、不，六目、八目相对……然后平静一下，抽冷子再去领导屋继续谈。让女生哭着离开办公室，对校领导的风评是有损的，很容易传闲话，校领导坐不住的。啥？校长是女的？那书记呢？不可能班子成员都是女的。）

如果学校还是不让步（就算校长犯昏，别人也不劝他？学校法务干啥吃的？办公室主任干啥吃的？他们早都给领导点明后果了。），那就真的要在各大网络平台发帖了。帖录音、帖录音整理的文字……帖子一定不要虚构和夸张，说事实说诉求就行了。接下来你自己都不用管，就会有政府负责网络舆情的部门联系学校的，你还担心学校继续不让步吗？

如果学校铁了心跟你死磕（实在想不出学校那么多管理人员为啥脑子集体发昏），那就法院诉讼啦，肯定能赢的。不过我想只要你发挥主动性，积极去解决，是走不到到这最后一步的，早早就在学校内部的时候就搞定了。

很少有人不基于框架直接写GUI界面啦，我这个回答就从GUI框架反过来推什么语言做GUI合适。（只聊桌面端GUI编程框架）

Qt

几乎是C++领域最流行的跨平台桌面端软件开发框架了，这个框架是两个挪威人在1995年创建的，发展至今可以说历史相当悠久，稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。

它内置了自绘引擎，也就是说界面上的一个按钮，一个文本框，都是Qt的引擎自己画的，这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。

它提供了大量的与界面无关但与软件开发息息相关的API，比如、网络、文件系统、剪切板等，而且让这些API在不同的操作系统下都有效，这极大的节省了开发人员的时间。

但它也有一些缺点，比如在处理一些特殊需求上很不方便，比如：目前Qt有没有比较好解决高分屏下缩放显示的方案？，Qt没有真正完美的无边框解决方案吗？等，在一些组件的渲染上也会出一些隐藏的较深的问题（QListItem），一旦遇到，就很难解决。

Qt近年来不太专一，qml，qtquick等，搞了很多，而且这些新玩意儿一直不温不火，有些模块做了又废弃了，比如：qt script，搞来搞去，搞的模块繁多且复杂，用起来不是很舒服。

Qt有界面描述语言（XML描述界面），可以通过设计器拖拽空间设计界面，编译期界面描述语言被转义成C++代码，性能上没啥损失。

Qt商业授权不太友好，开发商业应用一定要谨慎，之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接，会有版权上的限制，但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。

除了使用C++开发Qt应用外，开发者还可以使用其他语言开发Qt应用，最流行的就是使用Python基于PyQt做Qt应用了，其他语言的绑定不是很成熟，但PyQt仍然有版权的问题。

GTK

GTK是1997年创建的，也非常成熟稳定，是C语言开发的，但有很多语言的绑定，比如官方支持的JavaScript、Rust等，当然用C++语言操作GTK也很方便，它也有自绘引擎（Cairo），也提供了大量系统相关的API，商业授权也非常友好，基于GTK开发商业软件不用担心收到律师函的问题，虽然它是一个跨平台桌面软件，但它似乎只在Linux操作系统领域流行，有非常多的Linux桌面软件都是基于GTK开发的。

这也直接导致GTK的维护者很重视Linux领域的发展，而忽视Windows和Mac领域。这个框架提供的很多API，只在Linux下有，Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。

GTK在Windows上也没办法静态连接，它到不是因为版权的问题，而是它依赖MSYS2的一些库，这个库用于在Windows上模拟Linux环境，这也是为什么GTK在Windows上表现不佳的原因之一。

另外，由于GTK是C语言开发的，所以开发风格也很C语言化，这对于部分开发者来说可能觉得繁琐。

wxWidgets

wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件，也非常成熟稳定，商业授权非常友好。它没有自绘引擎，而是对不同平台下的界面API做了整合和封装，这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格，这对于某些软件来说，正是他们想要的，但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。

它是C++开发的，所以对C++开发者非常友好，除此之外它还支持静态连接，也就是说开发个应用不用分发给用户一大堆dll，当然Qt也支持静态连接，但是你得自己编译Qt的源码（不是很方便），而且Qt的授权规则也不允许普通开发者这么做。

它会有些小问题，比如我之前提的：wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice，但总体来说还是非常稳的。除了开发的界面比较死板外，没啥大的问题。目前使用这个框架开发软件的人越来越少了。

FLTK

fltk是1998年创建的跨平台开源GUI框架，历史悠久，商业授权友好，而且C++之父也用它，它非常轻量级，支持静态连接，一个简单的应用编译后只有500K左右，非常赞，

它有自己的自绘引擎，没记错的话用的是OpenGL，但它的重绘机制是按区域重绘的，如果组件A所在的区域上存在组件B，那么A组件重绘时，会把B组件的给重回掉，开发者必须自己写代码处理这种情况。想象一下，如果你想实现一个A组件fade out的同时B组件fade in的效果，就会非常麻烦。

FLTK提供的一些组件样式都比较刻板，绘图API也比较少，你想实现一个漂亮一点的圆角按钮（它内置圆角按钮的圆角大小是不能改的），必须自己画，而且还得借助一些非常奇葩的手段才行（如果你想知道，可以联系我）

它是C++开发的，但API不够现代，用起来总体还算舒服的，它有Rust绑定：fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API，但非常少，几乎可以忽略。

Duilib

是2010年国内一个开发者开发的GUI开发框架，因为底层基于DirectUI开发，所以只支持Windows平台，不支持跨平台，开源协议友好，商用没有任何问题（需要附加Lincence文件），国内有很多大厂基于这个技术做桌面端应用，比如网易、腾讯、百度，这个框架是基于C++开发的，对C++开发者友好。但框架本身还有一些问题，比如对高分屏支持不佳、特殊控件绘制上也有一些小问题，除了界面相关的API外，几乎没有提供系统级的API，作者纯粹是用爱发电来开发这个框架，所以更新不是很及时。

相对来说网易基于Duilib开发的分支更完善一些：NIM_Duilib_Framework，添加了高分屏支持、多国语言、整合了多线程处理的支持，但环境搭建相对比较麻烦。如果开发者要用这个框架，一定要用develop分支下的代码，master分支下的代码问题很多，这个框架看上去也是作者一个人努力的成果。

Sciter

Sciter是2006年创建的跨平台闭源GUI框架，足够稳定，商业授权不友好，但个人开发者可以随便用（只能用动态链接库），一旦公司规模超过3人，就得买版权了（有权静态连接）。

它内部封了一个浏览器核心，让开发者使用HTML,CSS,JS来创建界面，但对这个浏览器核心做了大量的精简，不像Electron和NW.js动辄上百兆的体积，它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的，比如CSS3的flex布局，它就不支持（但它提供了自己的flex布局实现方式）。以前它使用自研的一个脚本语言（和JavaScript很像），自从集成了Fabrice Bellard大神的QuickJs之后，就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持，比如渲染大列表。

它使用C++开发，对C++开发者很友好，有Rust、go、Python等语言的绑定，但都是社区提供的，质量堪忧。有很多知名厂商都用这个库做界面，比如360、teamviewer、赛门铁克等。

RmlUi和Sciter很像，可以看成Sciter的替代框架，但RmlUi这个项目有三界作者，一个一个的弃坑不知道新任作者会不会弃坑，目前还不是很成熟，比如我正在尝试帮作者解决的CJK输入法的问题，目前还不推荐大家使用这个框架。

CEF

CEF是2008年创立的，基于Chromium的跨平台GUI框架，稳定且商业授权友好，国内很多大厂都用的CEF：比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio，装机量破亿。

由于它几乎封了一个完整的Chromium，所以体积非常大，但支持所有的HTMLCSSJS特性，它几乎不提供任何与操作系统相关的API，创建个托盘图标、读写个文件啥的，都要开发者自己完成，它是C/C++开发完成的，对C++用户非常友好，它有gopythonjava等语言的绑定，但都是社区提供的，质量值得担忧。

它对Chromium封装的很好，避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道，很多功能都有默认实现方式，遵从约定由于配置原则，有经验的C++开发者可以很轻松的驾驭CEF框架。

由于Chromium是版本弟，所以CEF版本发布也非常频繁，很多被标记为稳定的版本，还是会出一些莫名其妙的问题，选一个好的版本非常重要。

与Electron一样，它也是分主进程和渲染进程的，所以开发者要非常娴熟的运用跨进程通信的技术，虽然CEF提供了跨进程相关的API，但复杂度还是有点高的，使用的时候要认真细心。

MAUI

这是微软的跨平台GUI框架，不仅仅支持桌面端，还支持移动端，但官方并不支持Linux的桌面端（黑人问号，感觉与微软近些年向开放、开源的大方针相悖），这个框架新的狠，至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。

它是.NET平台下的GUI框架，有自绘引擎，对C#开发者很友好，界面依然是用XAML描述的，可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些，我觉得WPF没火起来跟XAML有直接关系。

使用这个框架开发桌面应用得封一个.NET框架给用户，当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。

Compose Multiplatform

这是JetBrains搞的跨平台GUI框架，也非常新，前段时间刚刚推出1.0.0版本，但这个版本还不是很稳，至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。

它的自绘引擎用的是Google的skia，这个自绘引擎稳的很，Chrome和Flutter都是用的它，所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。

JetBrains的东西当然对Kotlin开发者友好啦，Java生态下的很多东西你都能用，访问系统级API也没啥大问题，同样也得考虑封一个JRE给用户。

flutter-desktop

这是谷歌的跨平台开发框架，开源、免费、文档齐全、投入力度大且持久，同样也新的很，Windows版本刚刚发稳定版，Mac版本还没稳定。

如果你完全没搞过移动端的flutter，想用这个框架开发桌面应用，那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难，学习曲线比较平缓。

由于flutter在移动端积累了很多年，所以界面上的一些东西在desktop端都比较稳（skia自绘引擎），与操作系统相关的东西还不成熟，生态也不太好，比如你想订制一下窗口的标题栏，想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持，跟C/C++语言打交道很方便。

开发者直接使用Dart语言描述界面，这会导致众多大括号嵌套在一起的问题，可能很多开发者不习惯。

webview2

这是微软Edge浏览器团队推出的跨平台GUI引擎，是闭源的，目前只支持Windows，对C#和C++开发者友好，如果使用C#开发，就得考虑把.NET运行时分发给用户，如果使用C++开发，就得自己处理系统级API的操作，webview2本身是不对系统级API做封装的。

这个框架推出也没多久，很多API也还不稳定，更值得担忧的是这个团队，他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心，不知道他们会不会放弃webview2这个框架。

它的优势是可以复用系统当中已存在的webview2二进制资源，也就是说它虽然封了一个Chromium浏览器核心，但如果你可以确定客户电脑已经存在了基于webview2开发的应用，你的安装包体积可以足够小。

它也是多进程架构，甚至比Electron还要多一个进程（为了复用二进制资源），资源占用比较多。

webview

这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题，Mac上使用Cocoa/WebKit，Linux上使用gtk-webkit2，Windows 10上使用Edge（也就是上一个小节里提到的webview2），它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。

开源且免费（MIT）有go、Rust、Python等语言的绑定，不过官方支持的是go语言，C和C++，操作浏览器的API非常少，不支持自定义scheme，更别提系统级API了。

TAURI

采用的技术方案与webview类似，所以安装包也足够小，非常新，还没发布稳定版，开源免费。webview框架碰到的问题TAURI都有，

使用Rust开发，将来会支持Deno，作者说将来会直接使用webview的技术来支持多平台，

NW.js

NW.js最早把Chromium和Node绑定到一起，用前端知识做界面，用Node技术访问操作系统，最早叫node-webkit，在2012年创建。NW.js基于MIT开源，可以无忧使用。没记错的话，微信小程序开发工具是用NW.js开发的。作者是英特尔的员工，英特尔的一些工具也是用NW.js开发的。

除了Chromium和Node的能力外，NW.js自己也封装了一些系统级API，类似托盘图标、剪切板、系统菜单这种，但数量明显比Electron要少。

NW.js可以在多个窗口间共享同一个Node.js上下文，而且还可以通过配置让Node的上下文和Dom上下文混合，这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信，哪些模块当前进程不能用这类问题。

NW.js虽然起步早，但奈何没有杀手级应用，周边的生态和工具链没发展起来。用的人越来越少，维护的投入也不如Electron大，再加上Chromium更新非常频繁，导致NW.js的有些API也不是很稳，恶性循环加剧。

Electron

Electron的作者曾经在NW.js团队工作过（NW.js项目贡献第二多的人就是Electron的作者），后来辗转到了github公司，于2013年在创建了Electron，也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron，所以从者甚众，生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方（多进程架构及模块归属进程），但瑕不掩瑜。

Electron每创建一个窗口都会多一个进程，这使Electron创建窗口的效率不高（秒级），NW.js有复用进程的机制，即使新窗口加载完全不同域的页面也不会创建新的进程（毫秒级）。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。

无论是浏览器相关的API，还是系统级API，Electron提供的都比NW.js多。

--------2022-02-25更新--------

这些框架除了对开发者使用的编程语言有要求外，还有一个重要的差异就是有没有独立的界面描述语言（也就是UI DSL），这非常重要，涉及到一个框架表达业务的重要能力。

类似XAML、qt的ui文件、HTML+CSS都是界面描述语言，下面这种也可以算界面描述语言，但我感觉它不够纯粹（flutter、qml和Compose Multiplatform都是类似这样的）：

       panel {   row {     checkBox(...)     row {       textField(...) // indented relatively to the checkbox above     }   } }     

但无论如何，显而易见的是，没有任何一个界面描述语言能比的上HTML+CSS组合。想想看：HTML里各种花里胡哨的语义化标签和Dom操作技巧，CSS里的布局方式、伪元素、动画描述...，对比之下你就会觉得XAML、qml直流都是弟弟。

除此之外，一个优秀的GUI框架还有两个重要的需求，这里我简单聊聊：

强大的事件处理机制必不可少。

想想这些：鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外，还得处理事件冒泡、事件捕获、事件分发吧...

qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的（但影响很小）

强大的异步处理机制必不可少

你不能在用户处理业务逻辑的时候，让界面渲染工作阻塞，这就需要一个强大的异步处理机制，让开发者自己去开线程去完成业务处理，无疑是又麻烦又会增加开发者的心智负担。

我记得很早之前在C# WinForm应用中，点击一个按钮，如果不用Invoke执行逻辑处理的话，界面就会卡死。

这么看来，在你的GUI应用里包一个浏览器核心还是挺有必要的，这样你就可以用HTML+CSS强大的能力来描述你的界面，用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。

可能有人会想，这会带来很多问题呀，比如应用体积会增大的100M以上、会占用更多的CPU和内存资源，还会更耗电等等。

确实，目前来看这些都是问题，但仔细想想，这些问题应该不会持续太久，网络会变的更快，用户的磁盘和内存会变得更大，CPU处理能力也会更好，耗电的问题当然会持续存在，甚至会愈发耗电，但电的供应会持续增长呀。

web相关的技术之所以胜出，并不是这些技术的设计者有多厉害，而是这20多年间，有大量的人涌入了这个领域，前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答：

------------2022-02-27更新----------

用Web相关的技术做GUI应用的优势是，让开发者可以把大部分精力投注在业务本身上，而不是处理与GUI相关的技术细节。

实际上所有的框架，都应该是这个目的，比如ORM框架，目的应该是让开发者把大部分精力投注在业务与数据之间的关系上，而不是管理关系型数据的技术细节。

当然这肯定是有损耗的，在性能、稳定性、资源消耗上，都会有所削减。而且，因为有框架的存在，开发者很难深入到框架内部做一些特殊的事情。比如，我们该如何修改HTML的排版渲染机制呢？

所以，有些框架注重性能，有些框架注重开发效率，开发者做选择题的时候也应该衡量这两个问题，你的应用对哪些方面要求多一些呢？

你如果要开发一个视频监控系统，没多少业务功能，但要24小时不间断的记录视频数据，随时调取某一段时间的视频数据，这种应用可能Qt是最好的选择。

你如果要开发一个类似飞书的团队协作应用，业务逻辑复杂的一塌糊涂，而且要在短时间内满足更多用户的需求，占领更多的市场，那么Electron可能是更好的选择（目前飞书已经不再用Electron了，他们自己编译了Chromium核心，自己封了一个类似CEF的框架）

目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架，也在推各自的框架产品，说明桌面应用领域并没有没落，反而应该更加受到重视。

虽然移动端应用大行其道，但我认为，只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些，毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间，更强的存储和计算能力。

希望桌面软件开发领域的从业者都能获得幸福。

满屏荒唐言，一把辛酸泪，一把辛酸泪，一把辛酸泪...

---

  someok 网友的相关建议: 
      

很少有人不基于框架直接写GUI界面啦，我这个回答就从GUI框架反过来推什么语言做GUI合适。（只聊桌面端GUI编程框架）

Qt

几乎是C++领域最流行的跨平台桌面端软件开发框架了，这个框架是两个挪威人在1995年创建的，发展至今可以说历史相当悠久，稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。

它内置了自绘引擎，也就是说界面上的一个按钮，一个文本框，都是Qt的引擎自己画的，这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。

它提供了大量的与界面无关但与软件开发息息相关的API，比如、网络、文件系统、剪切板等，而且让这些API在不同的操作系统下都有效，这极大的节省了开发人员的时间。

但它也有一些缺点，比如在处理一些特殊需求上很不方便，比如：目前Qt有没有比较好解决高分屏下缩放显示的方案？，Qt没有真正完美的无边框解决方案吗？等，在一些组件的渲染上也会出一些隐藏的较深的问题（QListItem），一旦遇到，就很难解决。

Qt近年来不太专一，qml，qtquick等，搞了很多，而且这些新玩意儿一直不温不火，有些模块做了又废弃了，比如：qt script，搞来搞去，搞的模块繁多且复杂，用起来不是很舒服。

Qt有界面描述语言（XML描述界面），可以通过设计器拖拽空间设计界面，编译期界面描述语言被转义成C++代码，性能上没啥损失。

Qt商业授权不太友好，开发商业应用一定要谨慎，之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接，会有版权上的限制，但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。

除了使用C++开发Qt应用外，开发者还可以使用其他语言开发Qt应用，最流行的就是使用Python基于PyQt做Qt应用了，其他语言的绑定不是很成熟，但PyQt仍然有版权的问题。

GTK

GTK是1997年创建的，也非常成熟稳定，是C语言开发的，但有很多语言的绑定，比如官方支持的JavaScript、Rust等，当然用C++语言操作GTK也很方便，它也有自绘引擎（Cairo），也提供了大量系统相关的API，商业授权也非常友好，基于GTK开发商业软件不用担心收到律师函的问题，虽然它是一个跨平台桌面软件，但它似乎只在Linux操作系统领域流行，有非常多的Linux桌面软件都是基于GTK开发的。

这也直接导致GTK的维护者很重视Linux领域的发展，而忽视Windows和Mac领域。这个框架提供的很多API，只在Linux下有，Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。

GTK在Windows上也没办法静态连接，它到不是因为版权的问题，而是它依赖MSYS2的一些库，这个库用于在Windows上模拟Linux环境，这也是为什么GTK在Windows上表现不佳的原因之一。

另外，由于GTK是C语言开发的，所以开发风格也很C语言化，这对于部分开发者来说可能觉得繁琐。

wxWidgets

wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件，也非常成熟稳定，商业授权非常友好。它没有自绘引擎，而是对不同平台下的界面API做了整合和封装，这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格，这对于某些软件来说，正是他们想要的，但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。

它是C++开发的，所以对C++开发者非常友好，除此之外它还支持静态连接，也就是说开发个应用不用分发给用户一大堆dll，当然Qt也支持静态连接，但是你得自己编译Qt的源码（不是很方便），而且Qt的授权规则也不允许普通开发者这么做。

它会有些小问题，比如我之前提的：wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice，但总体来说还是非常稳的。除了开发的界面比较死板外，没啥大的问题。目前使用这个框架开发软件的人越来越少了。

FLTK

fltk是1998年创建的跨平台开源GUI框架，历史悠久，商业授权友好，而且C++之父也用它，它非常轻量级，支持静态连接，一个简单的应用编译后只有500K左右，非常赞，

它有自己的自绘引擎，没记错的话用的是OpenGL，但它的重绘机制是按区域重绘的，如果组件A所在的区域上存在组件B，那么A组件重绘时，会把B组件的给重回掉，开发者必须自己写代码处理这种情况。想象一下，如果你想实现一个A组件fade out的同时B组件fade in的效果，就会非常麻烦。

FLTK提供的一些组件样式都比较刻板，绘图API也比较少，你想实现一个漂亮一点的圆角按钮（它内置圆角按钮的圆角大小是不能改的），必须自己画，而且还得借助一些非常奇葩的手段才行（如果你想知道，可以联系我）

它是C++开发的，但API不够现代，用起来总体还算舒服的，它有Rust绑定：fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API，但非常少，几乎可以忽略。

Duilib

是2010年国内一个开发者开发的GUI开发框架，因为底层基于DirectUI开发，所以只支持Windows平台，不支持跨平台，开源协议友好，商用没有任何问题（需要附加Lincence文件），国内有很多大厂基于这个技术做桌面端应用，比如网易、腾讯、百度，这个框架是基于C++开发的，对C++开发者友好。但框架本身还有一些问题，比如对高分屏支持不佳、特殊控件绘制上也有一些小问题，除了界面相关的API外，几乎没有提供系统级的API，作者纯粹是用爱发电来开发这个框架，所以更新不是很及时。

相对来说网易基于Duilib开发的分支更完善一些：NIM_Duilib_Framework，添加了高分屏支持、多国语言、整合了多线程处理的支持，但环境搭建相对比较麻烦。如果开发者要用这个框架，一定要用develop分支下的代码，master分支下的代码问题很多，这个框架看上去也是作者一个人努力的成果。

Sciter

Sciter是2006年创建的跨平台闭源GUI框架，足够稳定，商业授权不友好，但个人开发者可以随便用（只能用动态链接库），一旦公司规模超过3人，就得买版权了（有权静态连接）。

它内部封了一个浏览器核心，让开发者使用HTML,CSS,JS来创建界面，但对这个浏览器核心做了大量的精简，不像Electron和NW.js动辄上百兆的体积，它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的，比如CSS3的flex布局，它就不支持（但它提供了自己的flex布局实现方式）。以前它使用自研的一个脚本语言（和JavaScript很像），自从集成了Fabrice Bellard大神的QuickJs之后，就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持，比如渲染大列表。

它使用C++开发，对C++开发者很友好，有Rust、go、Python等语言的绑定，但都是社区提供的，质量堪忧。有很多知名厂商都用这个库做界面，比如360、teamviewer、赛门铁克等。

RmlUi和Sciter很像，可以看成Sciter的替代框架，但RmlUi这个项目有三界作者，一个一个的弃坑不知道新任作者会不会弃坑，目前还不是很成熟，比如我正在尝试帮作者解决的CJK输入法的问题，目前还不推荐大家使用这个框架。

CEF

CEF是2008年创立的，基于Chromium的跨平台GUI框架，稳定且商业授权友好，国内很多大厂都用的CEF：比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio，装机量破亿。

由于它几乎封了一个完整的Chromium，所以体积非常大，但支持所有的HTMLCSSJS特性，它几乎不提供任何与操作系统相关的API，创建个托盘图标、读写个文件啥的，都要开发者自己完成，它是C/C++开发完成的，对C++用户非常友好，它有gopythonjava等语言的绑定，但都是社区提供的，质量值得担忧。

它对Chromium封装的很好，避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道，很多功能都有默认实现方式，遵从约定由于配置原则，有经验的C++开发者可以很轻松的驾驭CEF框架。

由于Chromium是版本弟，所以CEF版本发布也非常频繁，很多被标记为稳定的版本，还是会出一些莫名其妙的问题，选一个好的版本非常重要。

与Electron一样，它也是分主进程和渲染进程的，所以开发者要非常娴熟的运用跨进程通信的技术，虽然CEF提供了跨进程相关的API，但复杂度还是有点高的，使用的时候要认真细心。

MAUI

这是微软的跨平台GUI框架，不仅仅支持桌面端，还支持移动端，但官方并不支持Linux的桌面端（黑人问号，感觉与微软近些年向开放、开源的大方针相悖），这个框架新的狠，至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。

它是.NET平台下的GUI框架，有自绘引擎，对C#开发者很友好，界面依然是用XAML描述的，可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些，我觉得WPF没火起来跟XAML有直接关系。

使用这个框架开发桌面应用得封一个.NET框架给用户，当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。

Compose Multiplatform

这是JetBrains搞的跨平台GUI框架，也非常新，前段时间刚刚推出1.0.0版本，但这个版本还不是很稳，至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。

它的自绘引擎用的是Google的skia，这个自绘引擎稳的很，Chrome和Flutter都是用的它，所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。

JetBrains的东西当然对Kotlin开发者友好啦，Java生态下的很多东西你都能用，访问系统级API也没啥大问题，同样也得考虑封一个JRE给用户。

flutter-desktop

这是谷歌的跨平台开发框架，开源、免费、文档齐全、投入力度大且持久，同样也新的很，Windows版本刚刚发稳定版，Mac版本还没稳定。

如果你完全没搞过移动端的flutter，想用这个框架开发桌面应用，那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难，学习曲线比较平缓。

由于flutter在移动端积累了很多年，所以界面上的一些东西在desktop端都比较稳（skia自绘引擎），与操作系统相关的东西还不成熟，生态也不太好，比如你想订制一下窗口的标题栏，想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持，跟C/C++语言打交道很方便。

开发者直接使用Dart语言描述界面，这会导致众多大括号嵌套在一起的问题，可能很多开发者不习惯。

webview2

这是微软Edge浏览器团队推出的跨平台GUI引擎，是闭源的，目前只支持Windows，对C#和C++开发者友好，如果使用C#开发，就得考虑把.NET运行时分发给用户，如果使用C++开发，就得自己处理系统级API的操作，webview2本身是不对系统级API做封装的。

这个框架推出也没多久，很多API也还不稳定，更值得担忧的是这个团队，他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心，不知道他们会不会放弃webview2这个框架。

它的优势是可以复用系统当中已存在的webview2二进制资源，也就是说它虽然封了一个Chromium浏览器核心，但如果你可以确定客户电脑已经存在了基于webview2开发的应用，你的安装包体积可以足够小。

它也是多进程架构，甚至比Electron还要多一个进程（为了复用二进制资源），资源占用比较多。

webview

这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题，Mac上使用Cocoa/WebKit，Linux上使用gtk-webkit2，Windows 10上使用Edge（也就是上一个小节里提到的webview2），它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。

开源且免费（MIT）有go、Rust、Python等语言的绑定，不过官方支持的是go语言，C和C++，操作浏览器的API非常少，不支持自定义scheme，更别提系统级API了。

TAURI

采用的技术方案与webview类似，所以安装包也足够小，非常新，还没发布稳定版，开源免费。webview框架碰到的问题TAURI都有，

使用Rust开发，将来会支持Deno，作者说将来会直接使用webview的技术来支持多平台，

NW.js

NW.js最早把Chromium和Node绑定到一起，用前端知识做界面，用Node技术访问操作系统，最早叫node-webkit，在2012年创建。NW.js基于MIT开源，可以无忧使用。没记错的话，微信小程序开发工具是用NW.js开发的。作者是英特尔的员工，英特尔的一些工具也是用NW.js开发的。

除了Chromium和Node的能力外，NW.js自己也封装了一些系统级API，类似托盘图标、剪切板、系统菜单这种，但数量明显比Electron要少。

NW.js可以在多个窗口间共享同一个Node.js上下文，而且还可以通过配置让Node的上下文和Dom上下文混合，这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信，哪些模块当前进程不能用这类问题。

NW.js虽然起步早，但奈何没有杀手级应用，周边的生态和工具链没发展起来。用的人越来越少，维护的投入也不如Electron大，再加上Chromium更新非常频繁，导致NW.js的有些API也不是很稳，恶性循环加剧。

Electron

Electron的作者曾经在NW.js团队工作过（NW.js项目贡献第二多的人就是Electron的作者），后来辗转到了github公司，于2013年在创建了Electron，也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron，所以从者甚众，生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方（多进程架构及模块归属进程），但瑕不掩瑜。

Electron每创建一个窗口都会多一个进程，这使Electron创建窗口的效率不高（秒级），NW.js有复用进程的机制，即使新窗口加载完全不同域的页面也不会创建新的进程（毫秒级）。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。

无论是浏览器相关的API，还是系统级API，Electron提供的都比NW.js多。

--------2022-02-25更新--------

这些框架除了对开发者使用的编程语言有要求外，还有一个重要的差异就是有没有独立的界面描述语言（也就是UI DSL），这非常重要，涉及到一个框架表达业务的重要能力。

类似XAML、qt的ui文件、HTML+CSS都是界面描述语言，下面这种也可以算界面描述语言，但我感觉它不够纯粹（flutter、qml和Compose Multiplatform都是类似这样的）：

       panel {   row {     checkBox(...)     row {       textField(...) // indented relatively to the checkbox above     }   } }     

但无论如何，显而易见的是，没有任何一个界面描述语言能比的上HTML+CSS组合。想想看：HTML里各种花里胡哨的语义化标签和Dom操作技巧，CSS里的布局方式、伪元素、动画描述...，对比之下你就会觉得XAML、qml直流都是弟弟。

除此之外，一个优秀的GUI框架还有两个重要的需求，这里我简单聊聊：

强大的事件处理机制必不可少。

想想这些：鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外，还得处理事件冒泡、事件捕获、事件分发吧...

qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的（但影响很小）

强大的异步处理机制必不可少

你不能在用户处理业务逻辑的时候，让界面渲染工作阻塞，这就需要一个强大的异步处理机制，让开发者自己去开线程去完成业务处理，无疑是又麻烦又会增加开发者的心智负担。

我记得很早之前在C# WinForm应用中，点击一个按钮，如果不用Invoke执行逻辑处理的话，界面就会卡死。

这么看来，在你的GUI应用里包一个浏览器核心还是挺有必要的，这样你就可以用HTML+CSS强大的能力来描述你的界面，用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。

可能有人会想，这会带来很多问题呀，比如应用体积会增大的100M以上、会占用更多的CPU和内存资源，还会更耗电等等。

确实，目前来看这些都是问题，但仔细想想，这些问题应该不会持续太久，网络会变的更快，用户的磁盘和内存会变得更大，CPU处理能力也会更好，耗电的问题当然会持续存在，甚至会愈发耗电，但电的供应会持续增长呀。

web相关的技术之所以胜出，并不是这些技术的设计者有多厉害，而是这20多年间，有大量的人涌入了这个领域，前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答：

------------2022-02-27更新----------

用Web相关的技术做GUI应用的优势是，让开发者可以把大部分精力投注在业务本身上，而不是处理与GUI相关的技术细节。

实际上所有的框架，都应该是这个目的，比如ORM框架，目的应该是让开发者把大部分精力投注在业务与数据之间的关系上，而不是管理关系型数据的技术细节。

当然这肯定是有损耗的，在性能、稳定性、资源消耗上，都会有所削减。而且，因为有框架的存在，开发者很难深入到框架内部做一些特殊的事情。比如，我们该如何修改HTML的排版渲染机制呢？

所以，有些框架注重性能，有些框架注重开发效率，开发者做选择题的时候也应该衡量这两个问题，你的应用对哪些方面要求多一些呢？

你如果要开发一个视频监控系统，没多少业务功能，但要24小时不间断的记录视频数据，随时调取某一段时间的视频数据，这种应用可能Qt是最好的选择。

你如果要开发一个类似飞书的团队协作应用，业务逻辑复杂的一塌糊涂，而且要在短时间内满足更多用户的需求，占领更多的市场，那么Electron可能是更好的选择（目前飞书已经不再用Electron了，他们自己编译了Chromium核心，自己封了一个类似CEF的框架）

目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架，也在推各自的框架产品，说明桌面应用领域并没有没落，反而应该更加受到重视。

虽然移动端应用大行其道，但我认为，只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些，毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间，更强的存储和计算能力。

希望桌面软件开发领域的从业者都能获得幸福。

满屏荒唐言，一把辛酸泪，一把辛酸泪，一把辛酸泪...

---

  zhihusucks 网友的相关建议: 
      

很少有人不基于框架直接写GUI界面啦，我这个回答就从GUI框架反过来推什么语言做GUI合适。（只聊桌面端GUI编程框架）

Qt

几乎是C++领域最流行的跨平台桌面端软件开发框架了，这个框架是两个挪威人在1995年创建的，发展至今可以说历史相当悠久，稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。

它内置了自绘引擎，也就是说界面上的一个按钮，一个文本框，都是Qt的引擎自己画的，这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。

它提供了大量的与界面无关但与软件开发息息相关的API，比如、网络、文件系统、剪切板等，而且让这些API在不同的操作系统下都有效，这极大的节省了开发人员的时间。

但它也有一些缺点，比如在处理一些特殊需求上很不方便，比如：目前Qt有没有比较好解决高分屏下缩放显示的方案？，Qt没有真正完美的无边框解决方案吗？等，在一些组件的渲染上也会出一些隐藏的较深的问题（QListItem），一旦遇到，就很难解决。

Qt近年来不太专一，qml，qtquick等，搞了很多，而且这些新玩意儿一直不温不火，有些模块做了又废弃了，比如：qt script，搞来搞去，搞的模块繁多且复杂，用起来不是很舒服。

Qt有界面描述语言（XML描述界面），可以通过设计器拖拽空间设计界面，编译期界面描述语言被转义成C++代码，性能上没啥损失。

Qt商业授权不太友好，开发商业应用一定要谨慎，之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接，会有版权上的限制，但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。

除了使用C++开发Qt应用外，开发者还可以使用其他语言开发Qt应用，最流行的就是使用Python基于PyQt做Qt应用了，其他语言的绑定不是很成熟，但PyQt仍然有版权的问题。

GTK

GTK是1997年创建的，也非常成熟稳定，是C语言开发的，但有很多语言的绑定，比如官方支持的JavaScript、Rust等，当然用C++语言操作GTK也很方便，它也有自绘引擎（Cairo），也提供了大量系统相关的API，商业授权也非常友好，基于GTK开发商业软件不用担心收到律师函的问题，虽然它是一个跨平台桌面软件，但它似乎只在Linux操作系统领域流行，有非常多的Linux桌面软件都是基于GTK开发的。

这也直接导致GTK的维护者很重视Linux领域的发展，而忽视Windows和Mac领域。这个框架提供的很多API，只在Linux下有，Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。

GTK在Windows上也没办法静态连接，它到不是因为版权的问题，而是它依赖MSYS2的一些库，这个库用于在Windows上模拟Linux环境，这也是为什么GTK在Windows上表现不佳的原因之一。

另外，由于GTK是C语言开发的，所以开发风格也很C语言化，这对于部分开发者来说可能觉得繁琐。

wxWidgets

wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件，也非常成熟稳定，商业授权非常友好。它没有自绘引擎，而是对不同平台下的界面API做了整合和封装，这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格，这对于某些软件来说，正是他们想要的，但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。

它是C++开发的，所以对C++开发者非常友好，除此之外它还支持静态连接，也就是说开发个应用不用分发给用户一大堆dll，当然Qt也支持静态连接，但是你得自己编译Qt的源码（不是很方便），而且Qt的授权规则也不允许普通开发者这么做。

它会有些小问题，比如我之前提的：wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice，但总体来说还是非常稳的。除了开发的界面比较死板外，没啥大的问题。目前使用这个框架开发软件的人越来越少了。

FLTK

fltk是1998年创建的跨平台开源GUI框架，历史悠久，商业授权友好，而且C++之父也用它，它非常轻量级，支持静态连接，一个简单的应用编译后只有500K左右，非常赞，

它有自己的自绘引擎，没记错的话用的是OpenGL，但它的重绘机制是按区域重绘的，如果组件A所在的区域上存在组件B，那么A组件重绘时，会把B组件的给重回掉，开发者必须自己写代码处理这种情况。想象一下，如果你想实现一个A组件fade out的同时B组件fade in的效果，就会非常麻烦。

FLTK提供的一些组件样式都比较刻板，绘图API也比较少，你想实现一个漂亮一点的圆角按钮（它内置圆角按钮的圆角大小是不能改的），必须自己画，而且还得借助一些非常奇葩的手段才行（如果你想知道，可以联系我）

它是C++开发的，但API不够现代，用起来总体还算舒服的，它有Rust绑定：fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API，但非常少，几乎可以忽略。

Duilib

是2010年国内一个开发者开发的GUI开发框架，因为底层基于DirectUI开发，所以只支持Windows平台，不支持跨平台，开源协议友好，商用没有任何问题（需要附加Lincence文件），国内有很多大厂基于这个技术做桌面端应用，比如网易、腾讯、百度，这个框架是基于C++开发的，对C++开发者友好。但框架本身还有一些问题，比如对高分屏支持不佳、特殊控件绘制上也有一些小问题，除了界面相关的API外，几乎没有提供系统级的API，作者纯粹是用爱发电来开发这个框架，所以更新不是很及时。

相对来说网易基于Duilib开发的分支更完善一些：NIM_Duilib_Framework，添加了高分屏支持、多国语言、整合了多线程处理的支持，但环境搭建相对比较麻烦。如果开发者要用这个框架，一定要用develop分支下的代码，master分支下的代码问题很多，这个框架看上去也是作者一个人努力的成果。

Sciter

Sciter是2006年创建的跨平台闭源GUI框架，足够稳定，商业授权不友好，但个人开发者可以随便用（只能用动态链接库），一旦公司规模超过3人，就得买版权了（有权静态连接）。

它内部封了一个浏览器核心，让开发者使用HTML,CSS,JS来创建界面，但对这个浏览器核心做了大量的精简，不像Electron和NW.js动辄上百兆的体积，它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的，比如CSS3的flex布局，它就不支持（但它提供了自己的flex布局实现方式）。以前它使用自研的一个脚本语言（和JavaScript很像），自从集成了Fabrice Bellard大神的QuickJs之后，就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持，比如渲染大列表。

它使用C++开发，对C++开发者很友好，有Rust、go、Python等语言的绑定，但都是社区提供的，质量堪忧。有很多知名厂商都用这个库做界面，比如360、teamviewer、赛门铁克等。

RmlUi和Sciter很像，可以看成Sciter的替代框架，但RmlUi这个项目有三界作者，一个一个的弃坑不知道新任作者会不会弃坑，目前还不是很成熟，比如我正在尝试帮作者解决的CJK输入法的问题，目前还不推荐大家使用这个框架。

CEF

CEF是2008年创立的，基于Chromium的跨平台GUI框架，稳定且商业授权友好，国内很多大厂都用的CEF：比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio，装机量破亿。

由于它几乎封了一个完整的Chromium，所以体积非常大，但支持所有的HTMLCSSJS特性，它几乎不提供任何与操作系统相关的API，创建个托盘图标、读写个文件啥的，都要开发者自己完成，它是C/C++开发完成的，对C++用户非常友好，它有gopythonjava等语言的绑定，但都是社区提供的，质量值得担忧。

它对Chromium封装的很好，避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道，很多功能都有默认实现方式，遵从约定由于配置原则，有经验的C++开发者可以很轻松的驾驭CEF框架。

由于Chromium是版本弟，所以CEF版本发布也非常频繁，很多被标记为稳定的版本，还是会出一些莫名其妙的问题，选一个好的版本非常重要。

与Electron一样，它也是分主进程和渲染进程的，所以开发者要非常娴熟的运用跨进程通信的技术，虽然CEF提供了跨进程相关的API，但复杂度还是有点高的，使用的时候要认真细心。

MAUI

这是微软的跨平台GUI框架，不仅仅支持桌面端，还支持移动端，但官方并不支持Linux的桌面端（黑人问号，感觉与微软近些年向开放、开源的大方针相悖），这个框架新的狠，至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。

它是.NET平台下的GUI框架，有自绘引擎，对C#开发者很友好，界面依然是用XAML描述的，可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些，我觉得WPF没火起来跟XAML有直接关系。

使用这个框架开发桌面应用得封一个.NET框架给用户，当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。

Compose Multiplatform

这是JetBrains搞的跨平台GUI框架，也非常新，前段时间刚刚推出1.0.0版本，但这个版本还不是很稳，至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。

它的自绘引擎用的是Google的skia，这个自绘引擎稳的很，Chrome和Flutter都是用的它，所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。

JetBrains的东西当然对Kotlin开发者友好啦，Java生态下的很多东西你都能用，访问系统级API也没啥大问题，同样也得考虑封一个JRE给用户。

flutter-desktop

这是谷歌的跨平台开发框架，开源、免费、文档齐全、投入力度大且持久，同样也新的很，Windows版本刚刚发稳定版，Mac版本还没稳定。

如果你完全没搞过移动端的flutter，想用这个框架开发桌面应用，那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难，学习曲线比较平缓。

由于flutter在移动端积累了很多年，所以界面上的一些东西在desktop端都比较稳（skia自绘引擎），与操作系统相关的东西还不成熟，生态也不太好，比如你想订制一下窗口的标题栏，想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持，跟C/C++语言打交道很方便。

开发者直接使用Dart语言描述界面，这会导致众多大括号嵌套在一起的问题，可能很多开发者不习惯。

webview2

这是微软Edge浏览器团队推出的跨平台GUI引擎，是闭源的，目前只支持Windows，对C#和C++开发者友好，如果使用C#开发，就得考虑把.NET运行时分发给用户，如果使用C++开发，就得自己处理系统级API的操作，webview2本身是不对系统级API做封装的。

这个框架推出也没多久，很多API也还不稳定，更值得担忧的是这个团队，他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心，不知道他们会不会放弃webview2这个框架。

它的优势是可以复用系统当中已存在的webview2二进制资源，也就是说它虽然封了一个Chromium浏览器核心，但如果你可以确定客户电脑已经存在了基于webview2开发的应用，你的安装包体积可以足够小。

它也是多进程架构，甚至比Electron还要多一个进程（为了复用二进制资源），资源占用比较多。

webview

这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题，Mac上使用Cocoa/WebKit，Linux上使用gtk-webkit2，Windows 10上使用Edge（也就是上一个小节里提到的webview2），它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。

开源且免费（MIT）有go、Rust、Python等语言的绑定，不过官方支持的是go语言，C和C++，操作浏览器的API非常少，不支持自定义scheme，更别提系统级API了。

TAURI

采用的技术方案与webview类似，所以安装包也足够小，非常新，还没发布稳定版，开源免费。webview框架碰到的问题TAURI都有，

使用Rust开发，将来会支持Deno，作者说将来会直接使用webview的技术来支持多平台，

NW.js

NW.js最早把Chromium和Node绑定到一起，用前端知识做界面，用Node技术访问操作系统，最早叫node-webkit，在2012年创建。NW.js基于MIT开源，可以无忧使用。没记错的话，微信小程序开发工具是用NW.js开发的。作者是英特尔的员工，英特尔的一些工具也是用NW.js开发的。

除了Chromium和Node的能力外，NW.js自己也封装了一些系统级API，类似托盘图标、剪切板、系统菜单这种，但数量明显比Electron要少。

NW.js可以在多个窗口间共享同一个Node.js上下文，而且还可以通过配置让Node的上下文和Dom上下文混合，这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信，哪些模块当前进程不能用这类问题。

NW.js虽然起步早，但奈何没有杀手级应用，周边的生态和工具链没发展起来。用的人越来越少，维护的投入也不如Electron大，再加上Chromium更新非常频繁，导致NW.js的有些API也不是很稳，恶性循环加剧。

Electron

Electron的作者曾经在NW.js团队工作过（NW.js项目贡献第二多的人就是Electron的作者），后来辗转到了github公司，于2013年在创建了Electron，也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron，所以从者甚众，生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方（多进程架构及模块归属进程），但瑕不掩瑜。

Electron每创建一个窗口都会多一个进程，这使Electron创建窗口的效率不高（秒级），NW.js有复用进程的机制，即使新窗口加载完全不同域的页面也不会创建新的进程（毫秒级）。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。

无论是浏览器相关的API，还是系统级API，Electron提供的都比NW.js多。

--------2022-02-25更新--------

这些框架除了对开发者使用的编程语言有要求外，还有一个重要的差异就是有没有独立的界面描述语言（也就是UI DSL），这非常重要，涉及到一个框架表达业务的重要能力。

类似XAML、qt的ui文件、HTML+CSS都是界面描述语言，下面这种也可以算界面描述语言，但我感觉它不够纯粹（flutter、qml和Compose Multiplatform都是类似这样的）：

       panel {   row {     checkBox(...)     row {       textField(...) // indented relatively to the checkbox above     }   } }     

但无论如何，显而易见的是，没有任何一个界面描述语言能比的上HTML+CSS组合。想想看：HTML里各种花里胡哨的语义化标签和Dom操作技巧，CSS里的布局方式、伪元素、动画描述...，对比之下你就会觉得XAML、qml直流都是弟弟。

除此之外，一个优秀的GUI框架还有两个重要的需求，这里我简单聊聊：

强大的事件处理机制必不可少。

想想这些：鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外，还得处理事件冒泡、事件捕获、事件分发吧...

qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的（但影响很小）

强大的异步处理机制必不可少

你不能在用户处理业务逻辑的时候，让界面渲染工作阻塞，这就需要一个强大的异步处理机制，让开发者自己去开线程去完成业务处理，无疑是又麻烦又会增加开发者的心智负担。

我记得很早之前在C# WinForm应用中，点击一个按钮，如果不用Invoke执行逻辑处理的话，界面就会卡死。

这么看来，在你的GUI应用里包一个浏览器核心还是挺有必要的，这样你就可以用HTML+CSS强大的能力来描述你的界面，用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。

可能有人会想，这会带来很多问题呀，比如应用体积会增大的100M以上、会占用更多的CPU和内存资源，还会更耗电等等。

确实，目前来看这些都是问题，但仔细想想，这些问题应该不会持续太久，网络会变的更快，用户的磁盘和内存会变得更大，CPU处理能力也会更好，耗电的问题当然会持续存在，甚至会愈发耗电，但电的供应会持续增长呀。

web相关的技术之所以胜出，并不是这些技术的设计者有多厉害，而是这20多年间，有大量的人涌入了这个领域，前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答：

------------2022-02-27更新----------

用Web相关的技术做GUI应用的优势是，让开发者可以把大部分精力投注在业务本身上，而不是处理与GUI相关的技术细节。

实际上所有的框架，都应该是这个目的，比如ORM框架，目的应该是让开发者把大部分精力投注在业务与数据之间的关系上，而不是管理关系型数据的技术细节。

当然这肯定是有损耗的，在性能、稳定性、资源消耗上，都会有所削减。而且，因为有框架的存在，开发者很难深入到框架内部做一些特殊的事情。比如，我们该如何修改HTML的排版渲染机制呢？

所以，有些框架注重性能，有些框架注重开发效率，开发者做选择题的时候也应该衡量这两个问题，你的应用对哪些方面要求多一些呢？

你如果要开发一个视频监控系统，没多少业务功能，但要24小时不间断的记录视频数据，随时调取某一段时间的视频数据，这种应用可能Qt是最好的选择。

你如果要开发一个类似飞书的团队协作应用，业务逻辑复杂的一塌糊涂，而且要在短时间内满足更多用户的需求，占领更多的市场，那么Electron可能是更好的选择（目前飞书已经不再用Electron了，他们自己编译了Chromium核心，自己封了一个类似CEF的框架）

目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架，也在推各自的框架产品，说明桌面应用领域并没有没落，反而应该更加受到重视。

虽然移动端应用大行其道，但我认为，只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些，毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间，更强的存储和计算能力。

希望桌面软件开发领域的从业者都能获得幸福。

满屏荒唐言，一把辛酸泪，一把辛酸泪，一把辛酸泪...

---

  yingwuyi 网友的相关建议: 
      

很少有人不基于框架直接写GUI界面啦，我这个回答就从GUI框架反过来推什么语言做GUI合适。（只聊桌面端GUI编程框架）

Qt

几乎是C++领域最流行的跨平台桌面端软件开发框架了，这个框架是两个挪威人在1995年创建的，发展至今可以说历史相当悠久，稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。

它内置了自绘引擎，也就是说界面上的一个按钮，一个文本框，都是Qt的引擎自己画的，这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。

它提供了大量的与界面无关但与软件开发息息相关的API，比如、网络、文件系统、剪切板等，而且让这些API在不同的操作系统下都有效，这极大的节省了开发人员的时间。

但它也有一些缺点，比如在处理一些特殊需求上很不方便，比如：目前Qt有没有比较好解决高分屏下缩放显示的方案？，Qt没有真正完美的无边框解决方案吗？等，在一些组件的渲染上也会出一些隐藏的较深的问题（QListItem），一旦遇到，就很难解决。

Qt近年来不太专一，qml，qtquick等，搞了很多，而且这些新玩意儿一直不温不火，有些模块做了又废弃了，比如：qt script，搞来搞去，搞的模块繁多且复杂，用起来不是很舒服。

Qt有界面描述语言（XML描述界面），可以通过设计器拖拽空间设计界面，编译期界面描述语言被转义成C++代码，性能上没啥损失。

Qt商业授权不太友好，开发商业应用一定要谨慎，之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接，会有版权上的限制，但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。

除了使用C++开发Qt应用外，开发者还可以使用其他语言开发Qt应用，最流行的就是使用Python基于PyQt做Qt应用了，其他语言的绑定不是很成熟，但PyQt仍然有版权的问题。

GTK

GTK是1997年创建的，也非常成熟稳定，是C语言开发的，但有很多语言的绑定，比如官方支持的JavaScript、Rust等，当然用C++语言操作GTK也很方便，它也有自绘引擎（Cairo），也提供了大量系统相关的API，商业授权也非常友好，基于GTK开发商业软件不用担心收到律师函的问题，虽然它是一个跨平台桌面软件，但它似乎只在Linux操作系统领域流行，有非常多的Linux桌面软件都是基于GTK开发的。

这也直接导致GTK的维护者很重视Linux领域的发展，而忽视Windows和Mac领域。这个框架提供的很多API，只在Linux下有，Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。

GTK在Windows上也没办法静态连接，它到不是因为版权的问题，而是它依赖MSYS2的一些库，这个库用于在Windows上模拟Linux环境，这也是为什么GTK在Windows上表现不佳的原因之一。

另外，由于GTK是C语言开发的，所以开发风格也很C语言化，这对于部分开发者来说可能觉得繁琐。

wxWidgets

wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件，也非常成熟稳定，商业授权非常友好。它没有自绘引擎，而是对不同平台下的界面API做了整合和封装，这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格，这对于某些软件来说，正是他们想要的，但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。

它是C++开发的，所以对C++开发者非常友好，除此之外它还支持静态连接，也就是说开发个应用不用分发给用户一大堆dll，当然Qt也支持静态连接，但是你得自己编译Qt的源码（不是很方便），而且Qt的授权规则也不允许普通开发者这么做。

它会有些小问题，比如我之前提的：wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice，但总体来说还是非常稳的。除了开发的界面比较死板外，没啥大的问题。目前使用这个框架开发软件的人越来越少了。

FLTK

fltk是1998年创建的跨平台开源GUI框架，历史悠久，商业授权友好，而且C++之父也用它，它非常轻量级，支持静态连接，一个简单的应用编译后只有500K左右，非常赞，

它有自己的自绘引擎，没记错的话用的是OpenGL，但它的重绘机制是按区域重绘的，如果组件A所在的区域上存在组件B，那么A组件重绘时，会把B组件的给重回掉，开发者必须自己写代码处理这种情况。想象一下，如果你想实现一个A组件fade out的同时B组件fade in的效果，就会非常麻烦。

FLTK提供的一些组件样式都比较刻板，绘图API也比较少，你想实现一个漂亮一点的圆角按钮（它内置圆角按钮的圆角大小是不能改的），必须自己画，而且还得借助一些非常奇葩的手段才行（如果你想知道，可以联系我）

它是C++开发的，但API不够现代，用起来总体还算舒服的，它有Rust绑定：fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API，但非常少，几乎可以忽略。

Duilib

是2010年国内一个开发者开发的GUI开发框架，因为底层基于DirectUI开发，所以只支持Windows平台，不支持跨平台，开源协议友好，商用没有任何问题（需要附加Lincence文件），国内有很多大厂基于这个技术做桌面端应用，比如网易、腾讯、百度，这个框架是基于C++开发的，对C++开发者友好。但框架本身还有一些问题，比如对高分屏支持不佳、特殊控件绘制上也有一些小问题，除了界面相关的API外，几乎没有提供系统级的API，作者纯粹是用爱发电来开发这个框架，所以更新不是很及时。

相对来说网易基于Duilib开发的分支更完善一些：NIM_Duilib_Framework，添加了高分屏支持、多国语言、整合了多线程处理的支持，但环境搭建相对比较麻烦。如果开发者要用这个框架，一定要用develop分支下的代码，master分支下的代码问题很多，这个框架看上去也是作者一个人努力的成果。

Sciter

Sciter是2006年创建的跨平台闭源GUI框架，足够稳定，商业授权不友好，但个人开发者可以随便用（只能用动态链接库），一旦公司规模超过3人，就得买版权了（有权静态连接）。

它内部封了一个浏览器核心，让开发者使用HTML,CSS,JS来创建界面，但对这个浏览器核心做了大量的精简，不像Electron和NW.js动辄上百兆的体积，它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的，比如CSS3的flex布局，它就不支持（但它提供了自己的flex布局实现方式）。以前它使用自研的一个脚本语言（和JavaScript很像），自从集成了Fabrice Bellard大神的QuickJs之后，就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持，比如渲染大列表。

它使用C++开发，对C++开发者很友好，有Rust、go、Python等语言的绑定，但都是社区提供的，质量堪忧。有很多知名厂商都用这个库做界面，比如360、teamviewer、赛门铁克等。

RmlUi和Sciter很像，可以看成Sciter的替代框架，但RmlUi这个项目有三界作者，一个一个的弃坑不知道新任作者会不会弃坑，目前还不是很成熟，比如我正在尝试帮作者解决的CJK输入法的问题，目前还不推荐大家使用这个框架。

CEF

CEF是2008年创立的，基于Chromium的跨平台GUI框架，稳定且商业授权友好，国内很多大厂都用的CEF：比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio，装机量破亿。

由于它几乎封了一个完整的Chromium，所以体积非常大，但支持所有的HTMLCSSJS特性，它几乎不提供任何与操作系统相关的API，创建个托盘图标、读写个文件啥的，都要开发者自己完成，它是C/C++开发完成的，对C++用户非常友好，它有gopythonjava等语言的绑定，但都是社区提供的，质量值得担忧。

它对Chromium封装的很好，避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道，很多功能都有默认实现方式，遵从约定由于配置原则，有经验的C++开发者可以很轻松的驾驭CEF框架。

由于Chromium是版本弟，所以CEF版本发布也非常频繁，很多被标记为稳定的版本，还是会出一些莫名其妙的问题，选一个好的版本非常重要。

与Electron一样，它也是分主进程和渲染进程的，所以开发者要非常娴熟的运用跨进程通信的技术，虽然CEF提供了跨进程相关的API，但复杂度还是有点高的，使用的时候要认真细心。

MAUI

这是微软的跨平台GUI框架，不仅仅支持桌面端，还支持移动端，但官方并不支持Linux的桌面端（黑人问号，感觉与微软近些年向开放、开源的大方针相悖），这个框架新的狠，至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。

它是.NET平台下的GUI框架，有自绘引擎，对C#开发者很友好，界面依然是用XAML描述的，可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些，我觉得WPF没火起来跟XAML有直接关系。

使用这个框架开发桌面应用得封一个.NET框架给用户，当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。

Compose Multiplatform

这是JetBrains搞的跨平台GUI框架，也非常新，前段时间刚刚推出1.0.0版本，但这个版本还不是很稳，至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。

它的自绘引擎用的是Google的skia，这个自绘引擎稳的很，Chrome和Flutter都是用的它，所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。

JetBrains的东西当然对Kotlin开发者友好啦，Java生态下的很多东西你都能用，访问系统级API也没啥大问题，同样也得考虑封一个JRE给用户。

flutter-desktop

这是谷歌的跨平台开发框架，开源、免费、文档齐全、投入力度大且持久，同样也新的很，Windows版本刚刚发稳定版，Mac版本还没稳定。

如果你完全没搞过移动端的flutter，想用这个框架开发桌面应用，那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难，学习曲线比较平缓。

由于flutter在移动端积累了很多年，所以界面上的一些东西在desktop端都比较稳（skia自绘引擎），与操作系统相关的东西还不成熟，生态也不太好，比如你想订制一下窗口的标题栏，想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持，跟C/C++语言打交道很方便。

开发者直接使用Dart语言描述界面，这会导致众多大括号嵌套在一起的问题，可能很多开发者不习惯。

webview2

这是微软Edge浏览器团队推出的跨平台GUI引擎，是闭源的，目前只支持Windows，对C#和C++开发者友好，如果使用C#开发，就得考虑把.NET运行时分发给用户，如果使用C++开发，就得自己处理系统级API的操作，webview2本身是不对系统级API做封装的。

这个框架推出也没多久，很多API也还不稳定，更值得担忧的是这个团队，他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心，不知道他们会不会放弃webview2这个框架。

它的优势是可以复用系统当中已存在的webview2二进制资源，也就是说它虽然封了一个Chromium浏览器核心，但如果你可以确定客户电脑已经存在了基于webview2开发的应用，你的安装包体积可以足够小。

它也是多进程架构，甚至比Electron还要多一个进程（为了复用二进制资源），资源占用比较多。

webview

这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题，Mac上使用Cocoa/WebKit，Linux上使用gtk-webkit2，Windows 10上使用Edge（也就是上一个小节里提到的webview2），它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。

开源且免费（MIT）有go、Rust、Python等语言的绑定，不过官方支持的是go语言，C和C++，操作浏览器的API非常少，不支持自定义scheme，更别提系统级API了。

TAURI

采用的技术方案与webview类似，所以安装包也足够小，非常新，还没发布稳定版，开源免费。webview框架碰到的问题TAURI都有，

使用Rust开发，将来会支持Deno，作者说将来会直接使用webview的技术来支持多平台，

NW.js

NW.js最早把Chromium和Node绑定到一起，用前端知识做界面，用Node技术访问操作系统，最早叫node-webkit，在2012年创建。NW.js基于MIT开源，可以无忧使用。没记错的话，微信小程序开发工具是用NW.js开发的。作者是英特尔的员工，英特尔的一些工具也是用NW.js开发的。

除了Chromium和Node的能力外，NW.js自己也封装了一些系统级API，类似托盘图标、剪切板、系统菜单这种，但数量明显比Electron要少。

NW.js可以在多个窗口间共享同一个Node.js上下文，而且还可以通过配置让Node的上下文和Dom上下文混合，这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信，哪些模块当前进程不能用这类问题。

NW.js虽然起步早，但奈何没有杀手级应用，周边的生态和工具链没发展起来。用的人越来越少，维护的投入也不如Electron大，再加上Chromium更新非常频繁，导致NW.js的有些API也不是很稳，恶性循环加剧。

Electron

Electron的作者曾经在NW.js团队工作过（NW.js项目贡献第二多的人就是Electron的作者），后来辗转到了github公司，于2013年在创建了Electron，也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron，所以从者甚众，生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方（多进程架构及模块归属进程），但瑕不掩瑜。

Electron每创建一个窗口都会多一个进程，这使Electron创建窗口的效率不高（秒级），NW.js有复用进程的机制，即使新窗口加载完全不同域的页面也不会创建新的进程（毫秒级）。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。

无论是浏览器相关的API，还是系统级API，Electron提供的都比NW.js多。

--------2022-02-25更新--------

这些框架除了对开发者使用的编程语言有要求外，还有一个重要的差异就是有没有独立的界面描述语言（也就是UI DSL），这非常重要，涉及到一个框架表达业务的重要能力。

类似XAML、qt的ui文件、HTML+CSS都是界面描述语言，下面这种也可以算界面描述语言，但我感觉它不够纯粹（flutter、qml和Compose Multiplatform都是类似这样的）：

       panel {   row {     checkBox(...)     row {       textField(...) // indented relatively to the checkbox above     }   } }     

但无论如何，显而易见的是，没有任何一个界面描述语言能比的上HTML+CSS组合。想想看：HTML里各种花里胡哨的语义化标签和Dom操作技巧，CSS里的布局方式、伪元素、动画描述...，对比之下你就会觉得XAML、qml直流都是弟弟。

除此之外，一个优秀的GUI框架还有两个重要的需求，这里我简单聊聊：

强大的事件处理机制必不可少。

想想这些：鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外，还得处理事件冒泡、事件捕获、事件分发吧...

qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的（但影响很小）

强大的异步处理机制必不可少

你不能在用户处理业务逻辑的时候，让界面渲染工作阻塞，这就需要一个强大的异步处理机制，让开发者自己去开线程去完成业务处理，无疑是又麻烦又会增加开发者的心智负担。

我记得很早之前在C# WinForm应用中，点击一个按钮，如果不用Invoke执行逻辑处理的话，界面就会卡死。

这么看来，在你的GUI应用里包一个浏览器核心还是挺有必要的，这样你就可以用HTML+CSS强大的能力来描述你的界面，用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。

可能有人会想，这会带来很多问题呀，比如应用体积会增大的100M以上、会占用更多的CPU和内存资源，还会更耗电等等。

确实，目前来看这些都是问题，但仔细想想，这些问题应该不会持续太久，网络会变的更快，用户的磁盘和内存会变得更大，CPU处理能力也会更好，耗电的问题当然会持续存在，甚至会愈发耗电，但电的供应会持续增长呀。

web相关的技术之所以胜出，并不是这些技术的设计者有多厉害，而是这20多年间，有大量的人涌入了这个领域，前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答：

------------2022-02-27更新----------

用Web相关的技术做GUI应用的优势是，让开发者可以把大部分精力投注在业务本身上，而不是处理与GUI相关的技术细节。

实际上所有的框架，都应该是这个目的，比如ORM框架，目的应该是让开发者把大部分精力投注在业务与数据之间的关系上，而不是管理关系型数据的技术细节。

当然这肯定是有损耗的，在性能、稳定性、资源消耗上，都会有所削减。而且，因为有框架的存在，开发者很难深入到框架内部做一些特殊的事情。比如，我们该如何修改HTML的排版渲染机制呢？

所以，有些框架注重性能，有些框架注重开发效率，开发者做选择题的时候也应该衡量这两个问题，你的应用对哪些方面要求多一些呢？

你如果要开发一个视频监控系统，没多少业务功能，但要24小时不间断的记录视频数据，随时调取某一段时间的视频数据，这种应用可能Qt是最好的选择。

你如果要开发一个类似飞书的团队协作应用，业务逻辑复杂的一塌糊涂，而且要在短时间内满足更多用户的需求，占领更多的市场，那么Electron可能是更好的选择（目前飞书已经不再用Electron了，他们自己编译了Chromium核心，自己封了一个类似CEF的框架）

目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架，也在推各自的框架产品，说明桌面应用领域并没有没落，反而应该更加受到重视。

虽然移动端应用大行其道，但我认为，只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些，毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间，更强的存储和计算能力。

希望桌面软件开发领域的从业者都能获得幸福。

满屏荒唐言，一把辛酸泪，一把辛酸泪，一把辛酸泪...

---

  wongbingming 网友的相关建议: 
      

很少有人不基于框架直接写GUI界面啦，我这个回答就从GUI框架反过来推什么语言做GUI合适。（只聊桌面端GUI编程框架）

Qt

几乎是C++领域最流行的跨平台桌面端软件开发框架了，这个框架是两个挪威人在1995年创建的，发展至今可以说历史相当悠久，稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。

它内置了自绘引擎，也就是说界面上的一个按钮，一个文本框，都是Qt的引擎自己画的，这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。

它提供了大量的与界面无关但与软件开发息息相关的API，比如、网络、文件系统、剪切板等，而且让这些API在不同的操作系统下都有效，这极大的节省了开发人员的时间。

但它也有一些缺点，比如在处理一些特殊需求上很不方便，比如：目前Qt有没有比较好解决高分屏下缩放显示的方案？，Qt没有真正完美的无边框解决方案吗？等，在一些组件的渲染上也会出一些隐藏的较深的问题（QListItem），一旦遇到，就很难解决。

Qt近年来不太专一，qml，qtquick等，搞了很多，而且这些新玩意儿一直不温不火，有些模块做了又废弃了，比如：qt script，搞来搞去，搞的模块繁多且复杂，用起来不是很舒服。

Qt有界面描述语言（XML描述界面），可以通过设计器拖拽空间设计界面，编译期界面描述语言被转义成C++代码，性能上没啥损失。

Qt商业授权不太友好，开发商业应用一定要谨慎，之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接，会有版权上的限制，但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。

除了使用C++开发Qt应用外，开发者还可以使用其他语言开发Qt应用，最流行的就是使用Python基于PyQt做Qt应用了，其他语言的绑定不是很成熟，但PyQt仍然有版权的问题。

GTK

GTK是1997年创建的，也非常成熟稳定，是C语言开发的，但有很多语言的绑定，比如官方支持的JavaScript、Rust等，当然用C++语言操作GTK也很方便，它也有自绘引擎（Cairo），也提供了大量系统相关的API，商业授权也非常友好，基于GTK开发商业软件不用担心收到律师函的问题，虽然它是一个跨平台桌面软件，但它似乎只在Linux操作系统领域流行，有非常多的Linux桌面软件都是基于GTK开发的。

这也直接导致GTK的维护者很重视Linux领域的发展，而忽视Windows和Mac领域。这个框架提供的很多API，只在Linux下有，Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。

GTK在Windows上也没办法静态连接，它到不是因为版权的问题，而是它依赖MSYS2的一些库，这个库用于在Windows上模拟Linux环境，这也是为什么GTK在Windows上表现不佳的原因之一。

另外，由于GTK是C语言开发的，所以开发风格也很C语言化，这对于部分开发者来说可能觉得繁琐。

wxWidgets

wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件，也非常成熟稳定，商业授权非常友好。它没有自绘引擎，而是对不同平台下的界面API做了整合和封装，这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格，这对于某些软件来说，正是他们想要的，但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。

它是C++开发的，所以对C++开发者非常友好，除此之外它还支持静态连接，也就是说开发个应用不用分发给用户一大堆dll，当然Qt也支持静态连接，但是你得自己编译Qt的源码（不是很方便），而且Qt的授权规则也不允许普通开发者这么做。

它会有些小问题，比如我之前提的：wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice，但总体来说还是非常稳的。除了开发的界面比较死板外，没啥大的问题。目前使用这个框架开发软件的人越来越少了。

FLTK

fltk是1998年创建的跨平台开源GUI框架，历史悠久，商业授权友好，而且C++之父也用它，它非常轻量级，支持静态连接，一个简单的应用编译后只有500K左右，非常赞，

它有自己的自绘引擎，没记错的话用的是OpenGL，但它的重绘机制是按区域重绘的，如果组件A所在的区域上存在组件B，那么A组件重绘时，会把B组件的给重回掉，开发者必须自己写代码处理这种情况。想象一下，如果你想实现一个A组件fade out的同时B组件fade in的效果，就会非常麻烦。

FLTK提供的一些组件样式都比较刻板，绘图API也比较少，你想实现一个漂亮一点的圆角按钮（它内置圆角按钮的圆角大小是不能改的），必须自己画，而且还得借助一些非常奇葩的手段才行（如果你想知道，可以联系我）

它是C++开发的，但API不够现代，用起来总体还算舒服的，它有Rust绑定：fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API，但非常少，几乎可以忽略。

Duilib

是2010年国内一个开发者开发的GUI开发框架，因为底层基于DirectUI开发，所以只支持Windows平台，不支持跨平台，开源协议友好，商用没有任何问题（需要附加Lincence文件），国内有很多大厂基于这个技术做桌面端应用，比如网易、腾讯、百度，这个框架是基于C++开发的，对C++开发者友好。但框架本身还有一些问题，比如对高分屏支持不佳、特殊控件绘制上也有一些小问题，除了界面相关的API外，几乎没有提供系统级的API，作者纯粹是用爱发电来开发这个框架，所以更新不是很及时。

相对来说网易基于Duilib开发的分支更完善一些：NIM_Duilib_Framework，添加了高分屏支持、多国语言、整合了多线程处理的支持，但环境搭建相对比较麻烦。如果开发者要用这个框架，一定要用develop分支下的代码，master分支下的代码问题很多，这个框架看上去也是作者一个人努力的成果。

Sciter

Sciter是2006年创建的跨平台闭源GUI框架，足够稳定，商业授权不友好，但个人开发者可以随便用（只能用动态链接库），一旦公司规模超过3人，就得买版权了（有权静态连接）。

它内部封了一个浏览器核心，让开发者使用HTML,CSS,JS来创建界面，但对这个浏览器核心做了大量的精简，不像Electron和NW.js动辄上百兆的体积，它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的，比如CSS3的flex布局，它就不支持（但它提供了自己的flex布局实现方式）。以前它使用自研的一个脚本语言（和JavaScript很像），自从集成了Fabrice Bellard大神的QuickJs之后，就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持，比如渲染大列表。

它使用C++开发，对C++开发者很友好，有Rust、go、Python等语言的绑定，但都是社区提供的，质量堪忧。有很多知名厂商都用这个库做界面，比如360、teamviewer、赛门铁克等。

RmlUi和Sciter很像，可以看成Sciter的替代框架，但RmlUi这个项目有三界作者，一个一个的弃坑不知道新任作者会不会弃坑，目前还不是很成熟，比如我正在尝试帮作者解决的CJK输入法的问题，目前还不推荐大家使用这个框架。

CEF

CEF是2008年创立的，基于Chromium的跨平台GUI框架，稳定且商业授权友好，国内很多大厂都用的CEF：比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio，装机量破亿。

由于它几乎封了一个完整的Chromium，所以体积非常大，但支持所有的HTMLCSSJS特性，它几乎不提供任何与操作系统相关的API，创建个托盘图标、读写个文件啥的，都要开发者自己完成，它是C/C++开发完成的，对C++用户非常友好，它有gopythonjava等语言的绑定，但都是社区提供的，质量值得担忧。

它对Chromium封装的很好，避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道，很多功能都有默认实现方式，遵从约定由于配置原则，有经验的C++开发者可以很轻松的驾驭CEF框架。

由于Chromium是版本弟，所以CEF版本发布也非常频繁，很多被标记为稳定的版本，还是会出一些莫名其妙的问题，选一个好的版本非常重要。

与Electron一样，它也是分主进程和渲染进程的，所以开发者要非常娴熟的运用跨进程通信的技术，虽然CEF提供了跨进程相关的API，但复杂度还是有点高的，使用的时候要认真细心。

MAUI

这是微软的跨平台GUI框架，不仅仅支持桌面端，还支持移动端，但官方并不支持Linux的桌面端（黑人问号，感觉与微软近些年向开放、开源的大方针相悖），这个框架新的狠，至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。

它是.NET平台下的GUI框架，有自绘引擎，对C#开发者很友好，界面依然是用XAML描述的，可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些，我觉得WPF没火起来跟XAML有直接关系。

使用这个框架开发桌面应用得封一个.NET框架给用户，当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。

Compose Multiplatform

这是JetBrains搞的跨平台GUI框架，也非常新，前段时间刚刚推出1.0.0版本，但这个版本还不是很稳，至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。

它的自绘引擎用的是Google的skia，这个自绘引擎稳的很，Chrome和Flutter都是用的它，所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。

JetBrains的东西当然对Kotlin开发者友好啦，Java生态下的很多东西你都能用，访问系统级API也没啥大问题，同样也得考虑封一个JRE给用户。

flutter-desktop

这是谷歌的跨平台开发框架，开源、免费、文档齐全、投入力度大且持久，同样也新的很，Windows版本刚刚发稳定版，Mac版本还没稳定。

如果你完全没搞过移动端的flutter，想用这个框架开发桌面应用，那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难，学习曲线比较平缓。

由于flutter在移动端积累了很多年，所以界面上的一些东西在desktop端都比较稳（skia自绘引擎），与操作系统相关的东西还不成熟，生态也不太好，比如你想订制一下窗口的标题栏，想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持，跟C/C++语言打交道很方便。

开发者直接使用Dart语言描述界面，这会导致众多大括号嵌套在一起的问题，可能很多开发者不习惯。

webview2

这是微软Edge浏览器团队推出的跨平台GUI引擎，是闭源的，目前只支持Windows，对C#和C++开发者友好，如果使用C#开发，就得考虑把.NET运行时分发给用户，如果使用C++开发，就得自己处理系统级API的操作，webview2本身是不对系统级API做封装的。

这个框架推出也没多久，很多API也还不稳定，更值得担忧的是这个团队，他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心，不知道他们会不会放弃webview2这个框架。

它的优势是可以复用系统当中已存在的webview2二进制资源，也就是说它虽然封了一个Chromium浏览器核心，但如果你可以确定客户电脑已经存在了基于webview2开发的应用，你的安装包体积可以足够小。

它也是多进程架构，甚至比Electron还要多一个进程（为了复用二进制资源），资源占用比较多。

webview

这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题，Mac上使用Cocoa/WebKit，Linux上使用gtk-webkit2，Windows 10上使用Edge（也就是上一个小节里提到的webview2），它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。

开源且免费（MIT）有go、Rust、Python等语言的绑定，不过官方支持的是go语言，C和C++，操作浏览器的API非常少，不支持自定义scheme，更别提系统级API了。

TAURI

采用的技术方案与webview类似，所以安装包也足够小，非常新，还没发布稳定版，开源免费。webview框架碰到的问题TAURI都有，

使用Rust开发，将来会支持Deno，作者说将来会直接使用webview的技术来支持多平台，

NW.js

NW.js最早把Chromium和Node绑定到一起，用前端知识做界面，用Node技术访问操作系统，最早叫node-webkit，在2012年创建。NW.js基于MIT开源，可以无忧使用。没记错的话，微信小程序开发工具是用NW.js开发的。作者是英特尔的员工，英特尔的一些工具也是用NW.js开发的。

除了Chromium和Node的能力外，NW.js自己也封装了一些系统级API，类似托盘图标、剪切板、系统菜单这种，但数量明显比Electron要少。

NW.js可以在多个窗口间共享同一个Node.js上下文，而且还可以通过配置让Node的上下文和Dom上下文混合，这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信，哪些模块当前进程不能用这类问题。

NW.js虽然起步早，但奈何没有杀手级应用，周边的生态和工具链没发展起来。用的人越来越少，维护的投入也不如Electron大，再加上Chromium更新非常频繁，导致NW.js的有些API也不是很稳，恶性循环加剧。

Electron

Electron的作者曾经在NW.js团队工作过（NW.js项目贡献第二多的人就是Electron的作者），后来辗转到了github公司，于2013年在创建了Electron，也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron，所以从者甚众，生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方（多进程架构及模块归属进程），但瑕不掩瑜。

Electron每创建一个窗口都会多一个进程，这使Electron创建窗口的效率不高（秒级），NW.js有复用进程的机制，即使新窗口加载完全不同域的页面也不会创建新的进程（毫秒级）。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。

无论是浏览器相关的API，还是系统级API，Electron提供的都比NW.js多。

--------2022-02-25更新--------

这些框架除了对开发者使用的编程语言有要求外，还有一个重要的差异就是有没有独立的界面描述语言（也就是UI DSL），这非常重要，涉及到一个框架表达业务的重要能力。

类似XAML、qt的ui文件、HTML+CSS都是界面描述语言，下面这种也可以算界面描述语言，但我感觉它不够纯粹（flutter、qml和Compose Multiplatform都是类似这样的）：

       panel {   row {     checkBox(...)     row {       textField(...) // indented relatively to the checkbox above     }   } }     

但无论如何，显而易见的是，没有任何一个界面描述语言能比的上HTML+CSS组合。想想看：HTML里各种花里胡哨的语义化标签和Dom操作技巧，CSS里的布局方式、伪元素、动画描述...，对比之下你就会觉得XAML、qml直流都是弟弟。

除此之外，一个优秀的GUI框架还有两个重要的需求，这里我简单聊聊：

强大的事件处理机制必不可少。

想想这些：鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外，还得处理事件冒泡、事件捕获、事件分发吧...

qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的（但影响很小）

强大的异步处理机制必不可少

你不能在用户处理业务逻辑的时候，让界面渲染工作阻塞，这就需要一个强大的异步处理机制，让开发者自己去开线程去完成业务处理，无疑是又麻烦又会增加开发者的心智负担。

我记得很早之前在C# WinForm应用中，点击一个按钮，如果不用Invoke执行逻辑处理的话，界面就会卡死。

这么看来，在你的GUI应用里包一个浏览器核心还是挺有必要的，这样你就可以用HTML+CSS强大的能力来描述你的界面，用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。

可能有人会想，这会带来很多问题呀，比如应用体积会增大的100M以上、会占用更多的CPU和内存资源，还会更耗电等等。

确实，目前来看这些都是问题，但仔细想想，这些问题应该不会持续太久，网络会变的更快，用户的磁盘和内存会变得更大，CPU处理能力也会更好，耗电的问题当然会持续存在，甚至会愈发耗电，但电的供应会持续增长呀。

web相关的技术之所以胜出，并不是这些技术的设计者有多厉害，而是这20多年间，有大量的人涌入了这个领域，前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答：

------------2022-02-27更新----------

用Web相关的技术做GUI应用的优势是，让开发者可以把大部分精力投注在业务本身上，而不是处理与GUI相关的技术细节。

实际上所有的框架，都应该是这个目的，比如ORM框架，目的应该是让开发者把大部分精力投注在业务与数据之间的关系上，而不是管理关系型数据的技术细节。

当然这肯定是有损耗的，在性能、稳定性、资源消耗上，都会有所削减。而且，因为有框架的存在，开发者很难深入到框架内部做一些特殊的事情。比如，我们该如何修改HTML的排版渲染机制呢？

所以，有些框架注重性能，有些框架注重开发效率，开发者做选择题的时候也应该衡量这两个问题，你的应用对哪些方面要求多一些呢？

你如果要开发一个视频监控系统，没多少业务功能，但要24小时不间断的记录视频数据，随时调取某一段时间的视频数据，这种应用可能Qt是最好的选择。

你如果要开发一个类似飞书的团队协作应用，业务逻辑复杂的一塌糊涂，而且要在短时间内满足更多用户的需求，占领更多的市场，那么Electron可能是更好的选择（目前飞书已经不再用Electron了，他们自己编译了Chromium核心，自己封了一个类似CEF的框架）

目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架，也在推各自的框架产品，说明桌面应用领域并没有没落，反而应该更加受到重视。

虽然移动端应用大行其道，但我认为，只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些，毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间，更强的存储和计算能力。

希望桌面软件开发领域的从业者都能获得幸福。

满屏荒唐言，一把辛酸泪，一把辛酸泪，一把辛酸泪...

---

  cnnblike 网友的相关建议: 
      

很少有人不基于框架直接写GUI界面啦，我这个回答就从GUI框架反过来推什么语言做GUI合适。（只聊桌面端GUI编程框架）

Qt

几乎是C++领域最流行的跨平台桌面端软件开发框架了，这个框架是两个挪威人在1995年创建的，发展至今可以说历史相当悠久，稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。

它内置了自绘引擎，也就是说界面上的一个按钮，一个文本框，都是Qt的引擎自己画的，这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。

它提供了大量的与界面无关但与软件开发息息相关的API，比如、网络、文件系统、剪切板等，而且让这些API在不同的操作系统下都有效，这极大的节省了开发人员的时间。

但它也有一些缺点，比如在处理一些特殊需求上很不方便，比如：目前Qt有没有比较好解决高分屏下缩放显示的方案？，Qt没有真正完美的无边框解决方案吗？等，在一些组件的渲染上也会出一些隐藏的较深的问题（QListItem），一旦遇到，就很难解决。

Qt近年来不太专一，qml，qtquick等，搞了很多，而且这些新玩意儿一直不温不火，有些模块做了又废弃了，比如：qt script，搞来搞去，搞的模块繁多且复杂，用起来不是很舒服。

Qt有界面描述语言（XML描述界面），可以通过设计器拖拽空间设计界面，编译期界面描述语言被转义成C++代码，性能上没啥损失。

Qt商业授权不太友好，开发商业应用一定要谨慎，之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接，会有版权上的限制，但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。

除了使用C++开发Qt应用外，开发者还可以使用其他语言开发Qt应用，最流行的就是使用Python基于PyQt做Qt应用了，其他语言的绑定不是很成熟，但PyQt仍然有版权的问题。

GTK

GTK是1997年创建的，也非常成熟稳定，是C语言开发的，但有很多语言的绑定，比如官方支持的JavaScript、Rust等，当然用C++语言操作GTK也很方便，它也有自绘引擎（Cairo），也提供了大量系统相关的API，商业授权也非常友好，基于GTK开发商业软件不用担心收到律师函的问题，虽然它是一个跨平台桌面软件，但它似乎只在Linux操作系统领域流行，有非常多的Linux桌面软件都是基于GTK开发的。

这也直接导致GTK的维护者很重视Linux领域的发展，而忽视Windows和Mac领域。这个框架提供的很多API，只在Linux下有，Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。

GTK在Windows上也没办法静态连接，它到不是因为版权的问题，而是它依赖MSYS2的一些库，这个库用于在Windows上模拟Linux环境，这也是为什么GTK在Windows上表现不佳的原因之一。

另外，由于GTK是C语言开发的，所以开发风格也很C语言化，这对于部分开发者来说可能觉得繁琐。

wxWidgets

wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件，也非常成熟稳定，商业授权非常友好。它没有自绘引擎，而是对不同平台下的界面API做了整合和封装，这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格，这对于某些软件来说，正是他们想要的，但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。

它是C++开发的，所以对C++开发者非常友好，除此之外它还支持静态连接，也就是说开发个应用不用分发给用户一大堆dll，当然Qt也支持静态连接，但是你得自己编译Qt的源码（不是很方便），而且Qt的授权规则也不允许普通开发者这么做。

它会有些小问题，比如我之前提的：wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice，但总体来说还是非常稳的。除了开发的界面比较死板外，没啥大的问题。目前使用这个框架开发软件的人越来越少了。

FLTK

fltk是1998年创建的跨平台开源GUI框架，历史悠久，商业授权友好，而且C++之父也用它，它非常轻量级，支持静态连接，一个简单的应用编译后只有500K左右，非常赞，

它有自己的自绘引擎，没记错的话用的是OpenGL，但它的重绘机制是按区域重绘的，如果组件A所在的区域上存在组件B，那么A组件重绘时，会把B组件的给重回掉，开发者必须自己写代码处理这种情况。想象一下，如果你想实现一个A组件fade out的同时B组件fade in的效果，就会非常麻烦。

FLTK提供的一些组件样式都比较刻板，绘图API也比较少，你想实现一个漂亮一点的圆角按钮（它内置圆角按钮的圆角大小是不能改的），必须自己画，而且还得借助一些非常奇葩的手段才行（如果你想知道，可以联系我）

它是C++开发的，但API不够现代，用起来总体还算舒服的，它有Rust绑定：fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API，但非常少，几乎可以忽略。

Duilib

是2010年国内一个开发者开发的GUI开发框架，因为底层基于DirectUI开发，所以只支持Windows平台，不支持跨平台，开源协议友好，商用没有任何问题（需要附加Lincence文件），国内有很多大厂基于这个技术做桌面端应用，比如网易、腾讯、百度，这个框架是基于C++开发的，对C++开发者友好。但框架本身还有一些问题，比如对高分屏支持不佳、特殊控件绘制上也有一些小问题，除了界面相关的API外，几乎没有提供系统级的API，作者纯粹是用爱发电来开发这个框架，所以更新不是很及时。

相对来说网易基于Duilib开发的分支更完善一些：NIM_Duilib_Framework，添加了高分屏支持、多国语言、整合了多线程处理的支持，但环境搭建相对比较麻烦。如果开发者要用这个框架，一定要用develop分支下的代码，master分支下的代码问题很多，这个框架看上去也是作者一个人努力的成果。

Sciter

Sciter是2006年创建的跨平台闭源GUI框架，足够稳定，商业授权不友好，但个人开发者可以随便用（只能用动态链接库），一旦公司规模超过3人，就得买版权了（有权静态连接）。

它内部封了一个浏览器核心，让开发者使用HTML,CSS,JS来创建界面，但对这个浏览器核心做了大量的精简，不像Electron和NW.js动辄上百兆的体积，它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的，比如CSS3的flex布局，它就不支持（但它提供了自己的flex布局实现方式）。以前它使用自研的一个脚本语言（和JavaScript很像），自从集成了Fabrice Bellard大神的QuickJs之后，就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持，比如渲染大列表。

它使用C++开发，对C++开发者很友好，有Rust、go、Python等语言的绑定，但都是社区提供的，质量堪忧。有很多知名厂商都用这个库做界面，比如360、teamviewer、赛门铁克等。

RmlUi和Sciter很像，可以看成Sciter的替代框架，但RmlUi这个项目有三界作者，一个一个的弃坑不知道新任作者会不会弃坑，目前还不是很成熟，比如我正在尝试帮作者解决的CJK输入法的问题，目前还不推荐大家使用这个框架。

CEF

CEF是2008年创立的，基于Chromium的跨平台GUI框架，稳定且商业授权友好，国内很多大厂都用的CEF：比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio，装机量破亿。

由于它几乎封了一个完整的Chromium，所以体积非常大，但支持所有的HTMLCSSJS特性，它几乎不提供任何与操作系统相关的API，创建个托盘图标、读写个文件啥的，都要开发者自己完成，它是C/C++开发完成的，对C++用户非常友好，它有gopythonjava等语言的绑定，但都是社区提供的，质量值得担忧。

它对Chromium封装的很好，避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道，很多功能都有默认实现方式，遵从约定由于配置原则，有经验的C++开发者可以很轻松的驾驭CEF框架。

由于Chromium是版本弟，所以CEF版本发布也非常频繁，很多被标记为稳定的版本，还是会出一些莫名其妙的问题，选一个好的版本非常重要。

与Electron一样，它也是分主进程和渲染进程的，所以开发者要非常娴熟的运用跨进程通信的技术，虽然CEF提供了跨进程相关的API，但复杂度还是有点高的，使用的时候要认真细心。

MAUI

这是微软的跨平台GUI框架，不仅仅支持桌面端，还支持移动端，但官方并不支持Linux的桌面端（黑人问号，感觉与微软近些年向开放、开源的大方针相悖），这个框架新的狠，至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。

它是.NET平台下的GUI框架，有自绘引擎，对C#开发者很友好，界面依然是用XAML描述的，可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些，我觉得WPF没火起来跟XAML有直接关系。

使用这个框架开发桌面应用得封一个.NET框架给用户，当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。

Compose Multiplatform

这是JetBrains搞的跨平台GUI框架，也非常新，前段时间刚刚推出1.0.0版本，但这个版本还不是很稳，至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。

它的自绘引擎用的是Google的skia，这个自绘引擎稳的很，Chrome和Flutter都是用的它，所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。

JetBrains的东西当然对Kotlin开发者友好啦，Java生态下的很多东西你都能用，访问系统级API也没啥大问题，同样也得考虑封一个JRE给用户。

flutter-desktop

这是谷歌的跨平台开发框架，开源、免费、文档齐全、投入力度大且持久，同样也新的很，Windows版本刚刚发稳定版，Mac版本还没稳定。

如果你完全没搞过移动端的flutter，想用这个框架开发桌面应用，那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难，学习曲线比较平缓。

由于flutter在移动端积累了很多年，所以界面上的一些东西在desktop端都比较稳（skia自绘引擎），与操作系统相关的东西还不成熟，生态也不太好，比如你想订制一下窗口的标题栏，想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持，跟C/C++语言打交道很方便。

开发者直接使用Dart语言描述界面，这会导致众多大括号嵌套在一起的问题，可能很多开发者不习惯。

webview2

这是微软Edge浏览器团队推出的跨平台GUI引擎，是闭源的，目前只支持Windows，对C#和C++开发者友好，如果使用C#开发，就得考虑把.NET运行时分发给用户，如果使用C++开发，就得自己处理系统级API的操作，webview2本身是不对系统级API做封装的。

这个框架推出也没多久，很多API也还不稳定，更值得担忧的是这个团队，他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心，不知道他们会不会放弃webview2这个框架。

它的优势是可以复用系统当中已存在的webview2二进制资源，也就是说它虽然封了一个Chromium浏览器核心，但如果你可以确定客户电脑已经存在了基于webview2开发的应用，你的安装包体积可以足够小。

它也是多进程架构，甚至比Electron还要多一个进程（为了复用二进制资源），资源占用比较多。

webview

这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题，Mac上使用Cocoa/WebKit，Linux上使用gtk-webkit2，Windows 10上使用Edge（也就是上一个小节里提到的webview2），它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。

开源且免费（MIT）有go、Rust、Python等语言的绑定，不过官方支持的是go语言，C和C++，操作浏览器的API非常少，不支持自定义scheme，更别提系统级API了。

TAURI

采用的技术方案与webview类似，所以安装包也足够小，非常新，还没发布稳定版，开源免费。webview框架碰到的问题TAURI都有，

使用Rust开发，将来会支持Deno，作者说将来会直接使用webview的技术来支持多平台，

NW.js

NW.js最早把Chromium和Node绑定到一起，用前端知识做界面，用Node技术访问操作系统，最早叫node-webkit，在2012年创建。NW.js基于MIT开源，可以无忧使用。没记错的话，微信小程序开发工具是用NW.js开发的。作者是英特尔的员工，英特尔的一些工具也是用NW.js开发的。

除了Chromium和Node的能力外，NW.js自己也封装了一些系统级API，类似托盘图标、剪切板、系统菜单这种，但数量明显比Electron要少。

NW.js可以在多个窗口间共享同一个Node.js上下文，而且还可以通过配置让Node的上下文和Dom上下文混合，这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信，哪些模块当前进程不能用这类问题。

NW.js虽然起步早，但奈何没有杀手级应用，周边的生态和工具链没发展起来。用的人越来越少，维护的投入也不如Electron大，再加上Chromium更新非常频繁，导致NW.js的有些API也不是很稳，恶性循环加剧。

Electron

Electron的作者曾经在NW.js团队工作过（NW.js项目贡献第二多的人就是Electron的作者），后来辗转到了github公司，于2013年在创建了Electron，也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron，所以从者甚众，生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方（多进程架构及模块归属进程），但瑕不掩瑜。

Electron每创建一个窗口都会多一个进程，这使Electron创建窗口的效率不高（秒级），NW.js有复用进程的机制，即使新窗口加载完全不同域的页面也不会创建新的进程（毫秒级）。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。

无论是浏览器相关的API，还是系统级API，Electron提供的都比NW.js多。

--------2022-02-25更新--------

这些框架除了对开发者使用的编程语言有要求外，还有一个重要的差异就是有没有独立的界面描述语言（也就是UI DSL），这非常重要，涉及到一个框架表达业务的重要能力。

类似XAML、qt的ui文件、HTML+CSS都是界面描述语言，下面这种也可以算界面描述语言，但我感觉它不够纯粹（flutter、qml和Compose Multiplatform都是类似这样的）：

       panel {   row {     checkBox(...)     row {       textField(...) // indented relatively to the checkbox above     }   } }     

但无论如何，显而易见的是，没有任何一个界面描述语言能比的上HTML+CSS组合。想想看：HTML里各种花里胡哨的语义化标签和Dom操作技巧，CSS里的布局方式、伪元素、动画描述...，对比之下你就会觉得XAML、qml直流都是弟弟。

除此之外，一个优秀的GUI框架还有两个重要的需求，这里我简单聊聊：

强大的事件处理机制必不可少。

想想这些：鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外，还得处理事件冒泡、事件捕获、事件分发吧...

qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的（但影响很小）

强大的异步处理机制必不可少

你不能在用户处理业务逻辑的时候，让界面渲染工作阻塞，这就需要一个强大的异步处理机制，让开发者自己去开线程去完成业务处理，无疑是又麻烦又会增加开发者的心智负担。

我记得很早之前在C# WinForm应用中，点击一个按钮，如果不用Invoke执行逻辑处理的话，界面就会卡死。

这么看来，在你的GUI应用里包一个浏览器核心还是挺有必要的，这样你就可以用HTML+CSS强大的能力来描述你的界面，用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。

可能有人会想，这会带来很多问题呀，比如应用体积会增大的100M以上、会占用更多的CPU和内存资源，还会更耗电等等。

确实，目前来看这些都是问题，但仔细想想，这些问题应该不会持续太久，网络会变的更快，用户的磁盘和内存会变得更大，CPU处理能力也会更好，耗电的问题当然会持续存在，甚至会愈发耗电，但电的供应会持续增长呀。

web相关的技术之所以胜出，并不是这些技术的设计者有多厉害，而是这20多年间，有大量的人涌入了这个领域，前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答：

------------2022-02-27更新----------

用Web相关的技术做GUI应用的优势是，让开发者可以把大部分精力投注在业务本身上，而不是处理与GUI相关的技术细节。

实际上所有的框架，都应该是这个目的，比如ORM框架，目的应该是让开发者把大部分精力投注在业务与数据之间的关系上，而不是管理关系型数据的技术细节。

当然这肯定是有损耗的，在性能、稳定性、资源消耗上，都会有所削减。而且，因为有框架的存在，开发者很难深入到框架内部做一些特殊的事情。比如，我们该如何修改HTML的排版渲染机制呢？

所以，有些框架注重性能，有些框架注重开发效率，开发者做选择题的时候也应该衡量这两个问题，你的应用对哪些方面要求多一些呢？

你如果要开发一个视频监控系统，没多少业务功能，但要24小时不间断的记录视频数据，随时调取某一段时间的视频数据，这种应用可能Qt是最好的选择。

你如果要开发一个类似飞书的团队协作应用，业务逻辑复杂的一塌糊涂，而且要在短时间内满足更多用户的需求，占领更多的市场，那么Electron可能是更好的选择（目前飞书已经不再用Electron了，他们自己编译了Chromium核心，自己封了一个类似CEF的框架）

目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架，也在推各自的框架产品，说明桌面应用领域并没有没落，反而应该更加受到重视。

虽然移动端应用大行其道，但我认为，只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些，毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间，更强的存储和计算能力。

希望桌面软件开发领域的从业者都能获得幸福。

满屏荒唐言，一把辛酸泪，一把辛酸泪，一把辛酸泪...

---