微软正在丢弃React
作者丨Afan Khan
编译丨诺亚
出品 | 技术栈（微信号：blog51cto）
最近，微软Edge团队撰写了一篇文章，引见了微软团队如何致力优化Edge阅读器的性能。但在文中，微软对React提出了批判，并发表他们将不再在Edge阅读器的开发中经常使用React。
我将具体解析他们的整篇文章内容，讨论这一选择对React、JavaScript开发者的影响，以及微软Edge团队面前的真正用意。
一、历史背景
显而易见，微软不宿愿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了。
对此，你怎样看呢？可以把你的想法写在评论区。
参考链接：
