基本上图形界面开发技术主要分为三类
(1) 基于组件和 layout开发
代表作 c++的 qt , c#的 winform
新生的比如 dart语言的 flutter
这种引擎的优点就是原生，内存占用小，效率高
(2) 基于某种特定领域模型语言仿前端开发
代表作 html+ css + js的 Electron, 移动端的 cordova/PhoneGap
其他的类库主要有
xaml + c#的 wpf
qml + js + c++的 qtquick
html + css + c# 的 blazor MAUI
html + css + js + rust 的 tauri
html + css + js + c/c#/python/rust 的 sciter
此类引擎的主要目标有两点 1. 跨移动端 2. 利用web前端的存量生态
html + css +js 的缺点主要是内存占用大，解析复杂，js语言不怎么滴
大部分都围绕着如何改进这些缺点而进行。
比如用 xaml 和 qml 来代替 html + css， 比如用 c# 脚本代替 js脚本
用 c++/rust/c#来代替 javascript进行后端开发
(3)由游戏引擎, opengl/3d技术发展而来的框架
比如 fltk,Unity 比较偏门， 就不讨论了

对于第一类型的框架，争议不大， 已成经典。
二代里纯 web技术栈开发的 Electron 没有问题, 其他各种类型的第二类仿制品，虽然从设计思路上是领先的，却很难成功,有以下几点原因:
1) xaml + qml + blazor + sciter 不能完全兼容html+css+js前端技术， 重建生态太难
   前端不用 js 脚本使用 c#的 wpf, blazor实际上是条邪路
2) 大部分方案均为使用其他后端语言代替 js开发， 这些语言真的适合后端开发吗？
   c++/rust根本不适合后端开发，只有前端js调用后端 java/c#可能只部分互联网公司的需求，目前没有一个这种方案的， 真做后端 js未必比 java/c#差， 而且还是前后端语言统一有优势， 对于c++/rust开发者来说，用前端方案自讨苦吃
3）使用特定领域描述语言进行开发，未必就比control/widget组件开发更合理
   大部分图形界面开发是简单的， 但是在一些部分专业领域的图形来说， 就需要很强的扩展能力并使用极为专业的特殊技术，比如opengl， 面向组件开发，能够很好的区分这些不同。
   而对于 XAML/QML 这种引擎来说， 需要理解其架构和底层技术才能够进行扩展，学习曲线十分陡峭。对于简单的开发，和widget难度差不多，对于特定数据扩展，则难度要远大于面向组件开发， 还要在不同的技术栈之间跳来跳去。
   即使是对于纯 html 5的 js 方案， canvas 和 webgl也是让人望而却步的， 大部分人都要远离这些东西， 索性前端确实是标准化影响大， 才有 threejs这种东西。但是微软或者qt公司，可没这么大影响力了

   从开发语言的生态来说， c++/c#/js的比较成熟， rust/go/dart(flutter)的生态太差。从效率上来说则以 c++/c#/rust优先， 而其他语言大多偏向于后端。
    
   总体来说，还是推荐经典的 qt widget/ c# winform/ Electron做界面开发， 近些年出现这些东西，投入进去坑可能比较多， 从语言的角度来说 c#几乎是完美的前后端统一语言， 但是微软总是尽可能在开发平台上排挤linux， 不太靠谱啊


    
    
  
--
修改:iwantfly FROM 111.199.191.*
FROM 111.199.191.*

好贴，看好各路大神都能下场发表深刻见解。

小小的跑个题，
“ 某种特定领域模型语言”，这个领域模型语言是UI届的术语吗？我理解领域模型是指不同行业的业务，描述领域模型得语言是UML，或者缩减版的什么。架构设计的书会这么叫。我很认同业务模型、概念模型、系统模型的三步骤。

另外我符方式二不那么悲观，是事物本质的体现，学了不会亏，可能会过时。
xaml和qml只是一种格式，方便自家的引擎解析排版、绑定函数、分发消息等等。
当然最直观的是将组件变成了“关键词、描述式”的。本意是降低方式一“基于组件”里
new组件、设置属性的复杂度，但描述式的需要要添加响应函数，处理消息和事件时，就出现了一锅烩的局面，乍看一眼xaml都晕了。相比cpp c#的一百个关键字来说，xaml里都不知道啥是关键字，啥是控件，啥是函数绑定，啥是内置框架，啥是第三方库。也就是你说的“稍一扩展就要理解整个框架反而难”。

但这是UI这个事儿本身的复杂度，不是这个方案方式搞复杂了。很多技术人员包括我自己，总会有UI啊给新来的写吧那谁谁几个老手去弄一下后面流程设计和算法（可能就是一系列业步骤）的事。

我还有个不成熟、甚至幼稚的想法。现在国产操作系统离推广不知还有多久。推之前可以先推个桌面软件UI开发框架与国标，基于二或者三，甚至搞个大厂随便指定下，收编开源。土壤没有可以先搞生态，反向推动。至少先把国有工业界软件统一了。实施也简单，作为软件验收标准就行。高校研究生实验室直接基于这个三方库做

可惜干实事儿的太少了，我听过的标准制定、评审会，大部分专家都迷恋设计纸面标准，没有干事儿，开头讲的高大上，后面一讲实现，就是基于开源加层皮，算是“验证概念”。当然这些会都是行业标准，不是关于UI的，我是有感而发。

【 在 iwantfly 的大作中提到: 】
: 基本上图形界面开发技术主要分为三类
: (1) 基于组件和 layout开发
: 代表作 c++的 qt , c#的 winform
: ...................
--
FROM 61.185.186.*

最适合写界面交互的语言其实是Kotlin，它的各种语法设计就是以UI交互为目标的，可以避免很多麻烦和问题。
而Java C# Rust等语言都不是专门为UI而设计的语言。
--
FROM 171.88.149.*

谢了，明白了。我没把俩词合在一起，
要不要自己系统内用DSL，王垠喷过，我觉得喷的挺对。
但实践中稍大的系统，都会或多或少上一个。比如配置文件里要动态估值，最后都是这条路。嵌入个通用的，比如lua或者什么的，反而少。

《小工到专家》那本书里也提到过DSL，作为工具箱里的工具。建议是实现一个功能全的特定领域语言，减少维护扩展的开销。

我同意王垠的观点，能不发明尽量别发明。用现成的lua python最好。
【 在 iwantfly 的大作中提到: 】
: DSL（Domain Specific Language）是针对某一领域，具有受限表达性的一种计算机程序设计语言。 常用于聚焦指定的领域或问题，要求 DSL 具备强大的表现力，同时在使用起来要简单。通常就是 xml, json, sql, markdown之类声明式语言
:  和你所说的领域模型是一个意思， 不过提起架构方面的领域模型， 我是看着就头大
:
--
FROM 124.114.151.*

这篇文章还只是简单的语法比较，不过已经算比较细了，你可以看看。
https://dev.to/vtsen/complete-c-to-kotlin-syntax-comparisons-1e86
堆界面代码，kotlin比C#更简洁，而且能保证非null安全，无论api层面还是应用代码。
实际上，kotlin把C#能抄的都抄了，C#做不了的都变成了劣势。


【 在 DoorWay 的大作中提到: 】
: 赞广博。
: 语法设计专为UI交互设计为目标？这个不懂哇，能举个例子吗，Kotlin的优势，c#的劣势？
--
FROM 171.88.149.*