最近，微软Edge团队撰写了一篇文章，介绍了微软团队如何努力提升Edge浏览器的性能。但在文中，微软对React提出了批评，并宣布他们将不再在Edge浏览器的开发中使用React。
我将详细解析他们的整篇文章内容，探讨这一决定对React、JavaScript开发者的影响，以及微软Edge团队背后的真正意图。
一、历史背景
微软Edge浏览器是基于Chromium构建的，Chromium是谷歌的一个开源网络浏览器项目。微软Edge的默认用户界面来源于Chromium。
显而易见，微软不希望Edge看起来像Chrome。因此，Edge拥有一套由微软设计的用户界面组件和元素。然而，这些组件是利用React开发的。
Edge中的许多小部件都是通过React创建的，它们共同构成了整个浏览器。
实际上，Edge浏览器并非一个彻头彻尾的React项目。它更像是一个精巧的拼图，通过HTML页面巧妙地嵌入了多个React驱动的小部件，诸如菜单、下拉列表以及收藏夹标签，都藏着React编织的小魔法。
可这样的做法并不那么灵光，尤其是面对那些鲜少变动的UI信息时，显得有点力不从心。其效率低下导致微软开始对React产生质疑。
但这个故事远未揭开全部真相。我们很快就会发现，到底是React有问题，还是微软在设计上存在人为缺陷。
二、问题所在
微软声称React效率不高，因此他们进行了改进，并于2024年5月28日发布的一篇文章中宣布了这一消息。
微软注意到，多个组件间共享的捆绑包过大，这导致了浏览器运行速度减慢。
理论上，这些组件不应共用一个捆绑包，但既然微软指出了这个问题，以下是他们的理由：
1.UI代码存在模块化问题。不同组件团队不当共享了通用代码包和文件，导致UI界面中一个区域因加载了不必要的共享资源而拖累了另一个区域的加载速度。
2.微软采用了一个框架，该框架依赖JavaScript，通过客户端渲染技术来呈现UI。微软声称，这是导致其浏览器速度变慢的第二个原因。
如前所述，Edge浏览器中集成了多个React应用。
他们并未启动多个React项目，而是在多个位置使用了一个单一的JavaScript包，并将该包挂载到了许多组件中的多个属性上。
而第二个原因正是我撰写本文的缘由。微软间接地指出，React正是导致其代码包问题的框架。
图片
微软时不时提及React，是因为他们正全速推进像React Native这样针对Windows、MacOS乃至Xbox的项目。但对于Edge浏览器，React似乎成了他们不愿触及的“逆鳞”。
即便是亲手操刀React Native的开发，微软也迟迟未让其涉足Edge的领地。作为一款原生桌面应用，Edge与React Native看似天作之合，但微软对此有不同的看法。
过去，借助HTML、CSS、JavaScript，乃至React来搭建菜单、下拉框等界面元素，是业界的“金科玉律”。而今，微软决意转身，背后自有一番深思熟虑的考量。
图片
在过去，菜单及其选项通常是独立的HTML文件。每个执行特定操作的按钮或链接都会重定向到一个HTML文件。
然而，这种旧模式主要适用于诸如菜单之类的组件。但显然，微软并未完全理解这一点。
他们为每个简单的组件使用带有React的HTML文件。每个HTML文件都需要JavaScript。并且，他们将这些JavaScript代码作为捆绑包与每个团队共享。
微软将多个HTML页面（在React应用中）嵌入浏览器中以控制整个用户界面。现在，他们正在寻找解决这两个问题的办法。
三、解决方案
首先，问题并不在于React本身，而是微软错误地实施了它。
理想的状况下，每个代码包应服务于特定的网页，独立地完成其功能。每个页面可以有自己的独立代码包或集合。
但是，当你在不同团队的工作中共享相同的代码包或文件时，混乱几乎是必然的。每个团队都在访问和修改相同的代码包。
结果不出所料。React并非不适合他们的用途，而是他们使用方式不当。React本身并不慢，但当你创建了数十个实例时，就不能指望它还能保持极高的运行速度。
微软针对自己造成的问题提出了解决方案：他们创建了一个自定义框架。
微软宣布了WebUI 2.0——这是一种以标记优先的架构。它通过最小化代码包的大小及初始化路径中运行的JavaScript量，解决了代码包过大的问题。
微软已开始使用这一新架构来解决我前面提到的两个问题。他们错误地使用了React，忽略了React Native的存在，并解决了一个本可避免的问题。
起初，他们在每个组件中使用了含有React的独立HTML文件。然后，他们将每个HTML文件所需的JavaScript代码卸载到了一个共享包中，这个包同时供其他十个团队使用。而现在，他们不再使用React了。
对此，你怎么看呢？可以把你的想法写在评论区。
