第 602 期：开发者解释为什么他们宁愿开发网页而不是原生应用

当 WhatsApp 做出普遍被人讨厌的决定，将其原生 Windows 应用切换为 Web 网页套壳版时，大多数批评都指向了 Meta。这是理所当然的。这个决定显得懒惰，明显是占用内存的降级版本，并且去掉了应用在 Windows 上原本有限的 “原生” 体验。

但现实情况有些令人不适。

即便是 Meta，也没有太多动力去维持原生的 Windows 应用。这家公司几乎不更新它，也未实现功能一致性，而且最终默认使用了网页版。主要原因可能是因为，开发和维护 网页应用的成本更低。但真正的问题在于，微软并没有提供给开发者一个可以长期依赖的用户界面框架，网页应用则不存在这个问题。

最近，我们收到了一位我们的长期读者 Alexander 的来信，他也恰好是一名开发者。他提出的观点与许多开发者的感受不谋而合。

与 macOS 不同，macOS 尽管用户基数较小，却总能获得原生应用，开发者为 Windows 推出网页应用的态度并非出于便利，而是出于信任，或者更准确地说，是缺乏信任。

多年来，微软推出了多个 “未来式” 的框架，但后来又放弃了它们。从 WPF、Silverlight 到 UWP，再到现在的 WinUI 3，公司一直没有改变这种模式。正如 Alexander 所说，许多开发者现在假设，微软今天推出的任何东西可能都不会维持足够久，从而不足以支撑在其基础上进行开发。

数十年来，微软一直没有明确的界面开发的策略，而 Windows 现在提供了太多框架，却没有给开发者一个明确的使用指引。

了解这一点后，我对 Windows 网页应用的看法有所改变。当平台本身显得不稳定时，它们是一个备用选项。然而，微软最近对 Windows 完全原生应用的重视可能会改变这一局面。

Windows 从明确的发展路径变成了过多令人困惑的选择

曾经，开发 Windows 应用程序无需进行心理上的争论。早期的 Windows 开发围绕着一种单一且被充分理解的方法展开。Win32 是答案。一个 API，一个思维模型，以及完成任务的清晰方式。

查尔斯·佩佐尔德 (Charles Petzold) 的 《Programming Windows》（《Windows 编程》）被普遍认为是 Windows 开发的 “圣经”，它使开发变得易于接近，开发者可以放心地投入时间，因为平台不会在他们脚下突然发生变化。这种稳定性建立了信任，而信任促使生态系统增长。

然而，微软没有将 Win32 演进为更现代化的版本，而是不断引入新的层和替代方案。首先是作为 C++ 封装的 MFC。然后是为 .NET 开发者提供的 WinForms。随后是带有 XAML 和硬件加速渲染的 WPF。 Silverlight 作为跨平台尝试出现。接着是在 Windows 8 和 Windows 10 时代推出的 WinRT 和 UWP。如今，我们有了带有 Windows 应用 SDK 的 WinUI 3，以及用于跨平台开发的 MAUI。供开发者的选择，真是太多了。

上面提到的每一项技术发布时，都伴随着强有力的宣传，称其为 Windows 开发的未来。每一次发布都要求开发者投入时间，学习新的模式，并在其基础上进行开发。

问题并不在于这些技术本身不好。许多技术确实走在了时代的前列。问题在于，“未来” 总是在技术完全稳定前就被替代。开发者没有一个持续发展的单一平台，而是在不断追逐移动的目标。

Jeffrey Snover 在博客中详细指出，Windows 已经无法对一个简单问题给出清晰答案：应该如何构建一个 Windows 应用程序？

WPF 曾被视为未来，直到 Silverlight 出现，Silverlight 看上去很有前景，直到微软转向 HTML5。UWP 被推广为统一的平台，适用于所有应用，但即使在内部也未能完全采用。WinUI 3 现在被定位为现代解决方案，但它的路线图尚未激发开发者曾有的信心。

当微软推出具有明确方向的新框架时，开发者会开始采用它。随后策略会发生变化，关注点会转移到其他地方。以前的框架不一定会被官方淘汰，但它会慢慢失去相关性。这种循环重复了足够多次，以至于开发者停止完全投入。

正如 Alexander 所说，现今的普遍观点是，如果微软无法坚持以前的框架，又怎能假设当前的框架会有所不同？

这就是今天的状况。问一个开发者，他们应该使用什么来构建 Windows 应用，答案取决于您问的是谁。一些人仍会推荐 Win32。其他人偏好 WPF，因为它稳定。WinUI 3 被定位为现代，但尚未得到普遍信任。MAUI 存在于跨平台开发。还有使用 Electron 或 PWA 的网页路线。除此之外，第三方框架如 Avalonia 和 Qt 也在获得关注。

这并不是开发者所期待的那种选择，而是一片完全的不确定性。

为什么开发者选择 Web 应用而非原生应用

一些最受欢迎的 Windows 应用并非真正的原生应用。

WhatsApp、Spotify、Discord、Slack、Notion、Zoom，甚至微软自身生态系统的部分应用，是的，我说的是微软自家的 Teams（在重写之前）、Clipchamp 以及若干第一方体验都使用了 WebView2 网页套壳。

当然，如今构建一次性网页应用，并在各个平台上部署已经变得非常容易。它可以在 Windows、macOS、Linux 上运行，甚至可以在浏览器中运行，而无需维护多个代码库。像 Electron、基于 Chromium 的 WebView 和渐进式 Web 应用（PWA）这样的框架，使分发更加简单，更新更快速，开发成本更低。公司很难对此忽视。

微软转向 WebView2，将 Edge（Chromium）引擎嵌入到应用中。这对于保持一致性效果很好，但也意味着，许多 “桌面” 应用实际上只是运行在容器中的网页。

显而易见的缺点是，这些应用会消耗更多内存，响应速度较慢，而且与操作系统的集成不够深入。与此同时，运行多个 Electron 应用可能轻易耗尽系统资源，而原生应用在这方面传统上处理得更好。

在 macOS 和 iOS 上，开发者仍然优先考虑原生应用。即使是其他地方使用 Web 技术的公司，也会为苹果设备开发原生版本。这是因为，苹果一直保持着更加清晰的开发路径。像 Cocoa、AppKit 以及现今的 SwiftUI 等框架都得到了持续的支持和发展。开发者知道应该使用什么，更重要的是，他们知道这些技术在未来几年仍然会保持相关性。

而 Windows 没有同样的清晰度，开发者的反应也相应不同。因此，许多人选择使用 Web 技术，而不是赌一个可能会再次改变方向的框架。虽然它并不完美，在许多情况下，其桌面性能客观上更差，但它可以避免更大的风险——依赖微软下一步的决策。

微软正在尝试解决这个问题，但可能为时已晚

有迹象表明，微软意识到了这一问题。近期的努力表明，他们正在改善性能、减少对基于 Web 的组件的依赖，并在 Windows 上构建更多原生体验。Rudy Huyn 在其社交媒体上的发文欢迎开发者开发百分百原生应用，也被视为积极信号。

但是，仅仅修复应用本身只是问题的一部分。

即使微软在未来推出更优秀的原生应用，开发者仍然会犹豫不决。这种犹豫并非源自 WinUI 3 目前的能力或局限，而是源自其前身所经历的一切。多年的优先事项变动使开发者变得谨慎，而这种犹豫并不会在一夜之间消失。

如果微软希望改变这种局面，它应当完全投入到一个框架，并向开发者传达清楚。这也意味着，需要长期坚持一个框架，使其足够成熟，明确其发展方向，并提供全面支持。开发者需要一个可靠的路线图，以及在发生变化时明确的迁移路径。

真正的问题不在于技术，而在于一致性

微软并不缺乏能力。公司拥有业内顶尖的工程人才，也有长期构建强大开发工具的历史。它推出的许多框架从技术角度来看确实非常强大。

缺失的，是一致性。

Rebecca Sutter 在分析中提到，问题不在于技术故障，而是在于内部决策的一种模式，这种模式不断地改变方向。

这些决策反复导致开发者的不确定性。从外部来看，为什么这些变化会发生并不重要，重要的是结果。开发者面临多条路径，但没有一条让人感觉能够持久。

这就是为何当前情况看起来如此。问题不在于 Windows 选项太少，而在于没有一个选项让人感觉是最终确定的。开发者并不是在要求更多的框架，他们想要的是一个可以信赖的框架。

Web 网页套壳应用是症状，而非问题

Web 网页并不是因为更适合桌面计算而取代 Windows。在许多情况下，它们并不适合。它们取代 Windows，是因为它们为开发者提供了可靠性，而开发者不再愿意在 Windows 平台上投入。

开发者根据过去的经验做出审慎决定，无可厚非。

如果微软想要提升 Windows 应用的质量，解决方案不仅仅是承诺修复 Windows 11 和构建原生一方应用，而是要重建与开发者的信任，证明这一次，开发平台（WinUI3，我希望）将保持一致。

另外值得一提的是，如果您是一位高效能人士，拓扑梅尔智慧办公平台最近也更新了版本，带来了一些新的办公小工具，可以帮助您进一步提升日常工作效率。

您怎么看目前微软开发框架混乱的局面？您平常使用哪个界面框架进行开发呢？

本文来自：Developer explains why Windows 11 keeps getting web apps instead of native apps