UWP 正式宣告死亡

uwp 虽然不好看，但是流畅，

UWP 目前还是不会死透吧，毕竟能上架 Xbox 挺不错的。

不敢苟同，桌面开发 WPF 已经非常成熟完善了，分发就算不用 Windows Store ，用传统渠道也没问题，难道微软还能把 WPF 给吸回去么。

微软自己的软件用的不同的 GUI 技术那么多，其中一个换了个 GUI 就是 UWP 死啦？

2023 年了，还有人会有那种学一个技术终身用到老的思想？
Java 万古长青，你看看今年有多少人失业。
再说了，可能 UWP 不再维护什么的，但是它的接班人也是基于 XAML 的，这里面的思想都是一脉相承的。
我没学过 UWP ，但是我写过 WPF ，所以可以直接上手就写 UWP 的应用，非常简单。
一天到晚跨平台，如果要写的应用压根就没打算跨平台，用 Electron 这种空间巨无霸来写不是吃饱没事干吗。

感觉 xaml 很难用。。。

个人认为，之前一些系统级 UI 用 UWP 是因为 UWP XAML 这套界面库只能由 UWP 应用调用，但是那些系统级应用需要一些底层权限，于是微软不得不用 UWP+后门的方式来实现。
而现在 XAML Island 已经成熟了，就没必要再单独给 UWP 开后门了，于是就改回 Win32 了。
另外个人认为 UWP 早已死亡，因为 UWP 的重点是跨平台，在微软跨平台战略失败时就已经失去竞争力了。但是 UWP 背后的技术，如 XAML 、AppX ，短时间内不会死亡，不过用的人也不会太多。

windows phone 失败的时候 uwp 就死了，还用等现在？

微软搞死了很多东西，苏菲都快要寄了。WinUI 3 什么时候寄，拭目以待

因为 windows 上的 ui 技术非常多,其他的不是不想丢,是因为没得选.
但是肯定也会让用了 uwp 的人难受一阵,迁移也有成本

后续都 web 大一统吧,反正机器性能越来越强

wp7 无法升级到 wp8 ，搞了个 wp7.8
程序也无法兼容
典型的大企业做派

微软的很多东西都是这样的
跟着微软混。。

Lazarus 了解一下

Flutter 是一个可选项

打死都不用 Electron 凑合。。。一个 app 功能不大，文件大到几百兆，想想都可怕。

我们还用 winform

@forgottencoast 虽然我认为你肯定知道但是还是想提一嘴，electron 的优势远不止跨平台，选择 electron 相当于选择整个 web 生态。相比 Flutter 半生不熟、React Native 半生不死，electron 倒是最方便省心的框架了……那么丑陋的谁想用……但是在现在这个趋势又得捏着鼻子吃下去……

> 千万不要绑定到微软的技术栈上面

十几年前 wince 很火的时候我就意识到了，果断站队 linux

@manasheep WPF 到现在还是基于 D3D9 。也不可能有任何升到 D3D12 的希望。但凡你想集成点新的 feature 都要折腾死你。这能忍？

能用就行，前前公司还在用 Silverlight 做前台

除了 electron, 你们是不是忘了还可以用 unity 来写桌面的?

@asm 你是站在什么角度呢？开发，还是使用。。。

微软绕了一圈又回到原点

@Leon6868
你说的这个优势可能对前端程序员来说是的，但是这个世界上后端程序员应该比前端程序员多。

反正不能学微软的东西

@phub2020 无论开发还是使用，我都不会选择一个功能简单，但是一个 exe 文件就几百兆的软件

electron 可不凑合，js 写界面太香了，还能方便的接 native 代码，除了占资源，包大，简直完美

@phub2020 吐槽的角度。。。没别的，如果是开发肯定不用了，别人开发的用的不多，除了 Typora 是个例外。

@gniviliving 以后估计系统自动内置这些运行库，就像 .net 了，现在几百 M 的包是因为全部运行库全部自带

UWP 的最佳案例就是 苹果 转 arm 芯片

那些把自己绑定在某个技术栈上就不能脱身的人，说到底根本不适合搞开发。

所以不要担心某个公司会放弃什么产品，毕竟所有语言、所有架构的思想都是相通的。

@IDAEngine 现在也有，不打包浏览器运行库的，调用系统的浏览器内核，包比较小。

我装了个调节显示器亮度的工具：Twinkle Tray
这玩意要 300MB 硬盘空间和 500MB 内存容量，功能只有一个：调节显示器亮度……

要是不用 electron ，我觉得它可以做到 3MB 内存占用，几百 KB 文件大小。

每次这种新闻下面都有正确的废话。
“不要想一个技术用到老”，“思想是相同的，语言不重要”

@ShadowPower 用 DDC/CI 作为关键词去找，应该很难找到这么大/臃肿的软件。

目前 win 上搞客户端，要么 cpp+directui,要么吃上了新的 winui ，要么用 Qt ，要么其他的就是各显神通的 python electron 之流的。 讲究性能的继续用 cpp ，不讲求效率的用 electron ，再不济的也得是 winform ，到了 wpf 面已经是很窄很窄了。

上面还有把失业跟 java 联系起来的，这什么神逻辑... 失业是整体的市场需求萎缩消失了， 需求才是决定你用什么语言的第一要素。

@sloknyyz electron 的话,有哪些语言可以扩展 js 的能力?之前我就是自己封装 cef,然后用 C#暴露 api 给 js 用,electron 如果也能用 C#扩展那就完美了

@xgfan 确实，一个技术很难用到老，但是技术研究投入都是有时间成本的，
思想是相通的，但是每个框架设计的理念不一样，真正使用的好都是要投入到细节里面去的，这个细节就是时间成本，我以前会 delphi ，但是我去学 swiftUI ，并没有感觉轻松，swift 各种闭包骚操作，让我觉得难受

@xgfan
试过同类的软件，都有兼容性问题
当然 macOS 平台能找到非 Electron 又能兼容的……

随着经济的不景气，技术也会安稳一段时间了

@bthulu #20 这位更是重量级

@forgottencoast
老板不关心这些，老板只关心前端程序员、后端程序员，谁工资低，就招谁，就用谁的技术。

我当年还用这个开发了一个 app 上架了，UI 用的是 uwp ，核心库用的是 C++。

Windows 上 GUI 框架就从来没有统一过，大厂是自绘，小厂是 CEF 流，还有 QT ，Electron 。

现在还在开发 wince