JavaScript 之父怒批 Windows 11 Web 化：Electron/WebView2 致性能臃肿

微软正在将 Windows 11 的大量功能——例如 Discord、Teams、开始菜单等——塞进 WebView2 或 Electron 构建的“壳”中。这种追求“Web化”的仓促设计，直接导致了应用高内存占用与系统卡顿，引发了 JavaScript 之父、Mozilla 联合创始人兼 Brave 浏览器 CEO Brendan Eich 的激烈批评。这位深耕 Web 技术领域的权威人士直指核心：这种做法正在牺牲 Windows 系统的原生体验优势。

大佬震怒：不是 Web 技术不行，是微软太敷衍

这场风波源于对 Windows 11 “Web 劣化”趋势的广泛报道。作为 Web 技术的奠基者之一，Brendan Eich 的批评并非针对 Web 技术本身，而是指向了微软敷衍的实现方式。他在社交媒体上明确指出：“Windows 11 更大的问题在于 WebView2 或 Electron。仓促地用 Web 体验替代原生应用，必然导致臃肿。Web 应用可以做得很好，但这需要足够的优化时间。”

Eich 也驳斥了“Web化是为了锁定订阅用户”的说法，认为这种乱象更多源于商业动机（例如从买断制转向订阅制、债务驱动开发等）。同时，他还点出了一个更深层的原因：现代 前端开发 中广泛使用的 NPM包管理器 在加速开发进程的同时，也无形中埋下了应用体积膨胀、依赖繁多的隐患。

这些 Win11 应用，被 Web 技术拖垮成“性能黑洞”

由 WebView2 和 Electron 引发的性能问题已经触目惊心，影响范围从第三方流行应用覆盖到了系统自身的核心功能。

1. Discord：基于 Electron 架构，其内存占用曾被用户报告最高可达 4GB。官方当时的解决方案仅仅是“内存超阈值后自动重启应用”这种治标不治本的方法，后续优化仅降低了约 5% 的内存占用，用户体验改善微乎其微。

2. Teams & WhatsApp：这两款应用都深度依赖 WebView2。Microsoft Teams 在闲置时也常驻 1-2GB 内存，其优化策略仅仅是将通话进程拆分开以避免界面卡顿。而 WhatsApp 桌面版曾有过一个优化极佳的原生版本，内存占用可控制在 200MB 以内；后来因开发团队变动，转而采用 WebView2 构建，导致内存占用飙升至 1GB 以上，是原先原生版本的数倍。

3. 系统功能：更令人担忧的是，Windows 11 自身的通知中心、Agenda 视图等核心功能也开始使用 WebView2 构建。打开这些功能便会新增一个 Edge 浏览器进程，内存占用从 1MB 左右瞬间飙升至 100MB。开始菜单、搜索界面等高频交互区域也采用了 Web 框架，成为了新的性能瓶颈。

核心矛盾：巨头为何连原生 UI 都懒做？

一个市值超过 3.5 万亿美元的科技巨头，为何不愿意为操作系统的基础功能开发高效的原生 UI？这背后的核心矛盾，是技术路线向商业利益的妥协。

采用 Web 技术进行开发，可以极大缩短开发周期、降低跨平台维护成本，让功能快速上线。然而，这种便利的代价被直接转移给了终端用户——更高的内存占用、更耗 CPU 以及更依赖网络。这甚至形成了一个恶性循环：Web 化导致性能下降，用户被迫升级硬件；而硬件的普遍升级又让企业更不重视底层优化，最终形成一个由用户买单的“性能税”怪圈。

行业警示：Web 技术不该是“偷懒”的借口

Brendan Eich 的批评，也是对整个行业的一个警示。Web 技术本身具有巨大的跨平台价值和开发效率优势，但它不应该成为开发者“偷懒”或企业压缩成本的借口。

一个优秀的 Web 应用同样需要精心设计和深度优化，而非简单地将网页打包成一个桌面应用就甩给用户。用户对于 Windows 11 上日益普遍的“Web 化”乱象早已怨声载道。或许只有持续不断的不满与反馈，才能倒逼像微软这样的企业进行反思，让流畅、高效的原生体验重新成为操作系统的核心追求。技术终究应该服务于用户体验，而不是成为商业妥协的牺牲品。

这场关于技术路线与用户体验的讨论，值得每一位开发者和技术决策者深思。如果你对这类技术趋势和开发者生态话题感兴趣，欢迎到 云栈社区 的开发者广场板块，与大家一同交流探讨。