开发者解析为何Windows 11频繁采用Web应用而非原生应用
Windows应用开发从单一稳定模式转向多个框架。 当WhatsApp决定将其原生Windows应用切换为网页封装版时，几乎所有批评都指向了Meta。这的确让人失望，明显是一种占用大量内存的退步，也几乎消除了该应用在Windows上的“原生”体验。
但事实情况更令人尴尬。
即使是Meta，也缺乏继续维护原生Windows应用的动力。公司几乎不再更新该应用，功能也没有达到同等水平，最终选择默认使用网页版。主要原因很可能是网页版应用更便宜且易维护，但真正的问题在于微软未能为开发者提供一个可以长期依赖的UI框架，而网页版应用则不存在这个问题。
我们最近收到了长期关注Windows Latest的读者、开发者Alexander Ovchinnikov的反馈。他的看法反映了许多开发者的感受。
与macOS不同，后者尽管用户基数较小，但始终拥有原生应用，开发者对只为Windows推网页应用的态度并非出于便利，而是基于对微软缺乏信任。
多年来，微软推出了多个所谓“未来”框架，却又很快放弃它们。从WPF和Silverlight，到UWP，再到现在的WinUI 3，这种模式从未改变。正如Alexander所说，许多开发者现在认为微软今天推广的技术可能不会持续足够久，无法让他们放心投入。
微软数十年未有明确的GUI战略，Windows提供了太多框架，却没有给开发者一个明确的选择。
了解到这些，我对Windows网页应用的看法发生了改变。当平台本身充满不确定时，网页应用成了最后的选择。不过，微软最近推动为Windows打造100%原生应用，可能会改变这种局面。
Windows从单一明确的开发路径变成了众多混乱选择
曾几何时，构建Windows应用不需纠结。早期的Windows开发围绕单一且明确的方法——Win32展开。一个API，一个思维模型，简单明了。
Charles Petzold的《Programming Windows》被公认为Windows开发的“圣经”，让开发者安心投入时间，因为平台不会轻易改变。这种稳定性带来了信任，也促使生态系统成长。
然而，微软并未让Win32变得现代化，而是不断引入新层和替代方案。先是MFC作为C++封装，然后是为.NET开发者设计的WinForms。接着是基于XAML和硬件加速渲染的WPF。Silverlight作为跨平台尝试出现。随后是Windows 8和10时代的WinRT与UWP。现在则是WinUI 3搭配Windows App SDK，以及跨平台的MAUI。
每个框架都被宣称是Windows开发的未来，都要求开发者投入时间学习新模式并构建应用。
问题不在于这些技术不好，很多真的很先进。问题是“未来”频繁更替，无法稳定发展。开发者被迫追逐不断变动的目标，而不是专注于一个不断发展的平台。
Jeffrey Snover的博客详细指出，Windows早已无法给出简单明了的答案：到底该如何构建Windows应用？
曾经，WPF被视为未来，直到Silverlight出现且看起来很有前景，随后微软转向HTML5。UWP被推为统一平台，但从未完全被采纳，即便是在内部。现在WinUI 3被定位为现代方案，但其路线图未能激发开发者如以往般的信心。
微软推出新框架时明确方向，开发者开始采用。但策略随即改变，关注点又转移。前一框架虽不一定被官方废弃，却慢慢失去意义。循环往复，导致开发者不再全心投入。
正如Alexander所说，如今的共识是，如果微软不能坚持过去的框架，为什么要相信当下的会有所不同？
这就是今天的状况。问开发者应该用什么开发Windows应用，答案五花八门。有的还推荐Win32，有的偏爱稳定的WPF，WinUI 3虽现代但尚未被普遍信任，MAUI用于跨平台，还有基于Electron或PWA的网页方案。此外，像Avalonia和Qt等第三方框架也越来越受欢迎。
这绝非开发者期待的选择，完全是无所适从。
为什么开发者选择网页应用而非原生？
一些最受欢迎的Windows应用并非真正的原生应用。WhatsApp、Spotify、Discord、Slack、Notion、Zoom，甚至微软自身生态中的微软Teams（重写前）、Clipchamp及若干一方应用都使用了WebView2。
微软Clipchamp当然，如今构建一次网页应用并多平台发布变得极其简单。它能运行在Windows、macOS、Linux，甚至浏览器中，无需维护多套代码。Electron、基于Chromium的WebView及渐进式网页应用使分发更便捷，更新更迅速，开发成本更低，企业难以抗拒。
微软转向WebView2，将Edge（Chromium）引擎嵌入应用中，保证体验一致，但也意味着很多“桌面”应用不过是运行在容器里的网页。
显而易见的缺点是，这些应用占用更多内存，响应较慢，与操作系统的集成程度较低。多个Electron应用同时运行时容易占满系统资源，而原生应用对此通常处理得更好。
截图中“WhatsApp”为新版，“WhatsApp Beta”为旧版UPW/WinUI应用在macOS和iOS上，开发者仍然优先考虑原生应用。即便一些公司在其他平台使用网页技术，仍会专门为苹果设备打造原生版本。这是因为苹果保持了更清晰的发展路线。Cocoa、AppKit以及如今的SwiftUI等框架得到了持续支持和发展。开发者知道如何选择，更重要的是，他们相信这些技术多年后依旧有用。
Windows则缺乏这样的清晰度，开发者也因此做出相应选择。
于是，很多人不愿押注可能再次变方向的框架，而选择了网页方案。虽不完美，很多情况下桌面性能也明显差一些，但它规避了对微软下一步决策的重大风险。
微软试图解决，但或许为时已晚
有迹象表明微软意识到了问题。最近的努力显示其正着手提升性能，减少对网页组件的依赖，打造更多Windows原生体验。Rudy Huyn在X平台上欢迎Windows开发者打造100%原生应用的帖文，反响积极。
但光修复应用本身只是一部分。
即便微软未来交出更好的原生应用，开发者仍会犹豫。他们的犹豫不是基于WinUI 3今天能做什么或不能做什么，而是基于过去所有经历。多年优先级反复变化让开发者变得小心翼翼，而这种犹豫不会一朝一夕消失。
若微软想改变这种状况，就必须全力以赴支持一个框架，并向开发者明确传达此事。这意味着要长期坚持支持一个框架，明确其发展方向并提供支持。开发者需要可靠的路线图，以及清晰的迁移方案以应对未来变化。
真正的问题不是技术，而是一致性
微软并不缺乏实力。公司拥有业内顶尖的工程人才，并在打造强大开发工具方面有着悠久历史。许多框架从技术角度来看都非常强大。
问题是，一直缺乏持续性。
Rebecca Sutter的分析指出，问题并非技术失败，而是一种内部决策反复摇摆的模式。
这重复造成开发者的不确定感。从外部看，变动原因并不重要，重要的是结果。开发者得到的是多个选择，却没有一个能让人信赖持久。
这就是今天局面的根源。问题不在于Windows选择太少，而是没有一个是明确且可靠的。开发者不需要更多框架，他们需要一个信得过的框架。
网页应用是症状，不是根本问题
网页应用并非因为更适合桌面计算才逐渐占领Windows市场。很多情况下，它们并不适合。它们之所以流行，是因为为那些不再信任Windows平台的开发者提供了可靠性。
开发者根据过去的经验做出理性选择，不能因此责怪他们。
如果微软想提升Windows应用的质量，解决方案不仅是承诺修复Windows 11和打造原生一方应用，更重要的是重建与开发者的信任，并证明这一次平台（希望是WinUI 3）会保持稳定。