我刚刚读到了一篇可能是我多年来读过的最有洞察力的文章。标题为“If Not React, Then What?”，作者为 Microsoft Edge 合作伙伴产品经理 Alex Russell。
这首曲子引起了我深刻的共鸣。当我通读它并点头同意每个段落时，很明显我必须与您分享。我开始记下真正击中要害的精彩引言，不久之后，我意识到我不能将自己的思考局限于几条推文——这值得有一个更广阔的舞台。
这篇文章仔细审视了整个前端生态系统，特别关注 React，提出了以大量数据和资源为基础的有充分支持的批评。它揭示了前端开发的严峻现实，挑战了行业的集体方向，并暴露了似乎占主导地位的“从众心态”。
严肃地说，这对于任何前端开发人员或架构师来说都是必不可少的读物。
如果不反应，那又怎样？
这是一本内容丰富的书——大约 9.5 万字——但在深入讨论之前，让我分享一些与我产生深刻共鸣的最引人注目的摘录
“简而言之，没有人应该在 2020 年代基于 React 启动新项目。句号。”
“这是真正工程的回报面，在充分理解的约束下尝试新材料以改善用户结果。”
“技术来来去去，但最重要的是对用户的关心。”
“……只有当需要 SPA 架构时，设计用于支持针对本地数据模型的乐观更新的工具（包括“前端框架”和“状态管理”工具）才应该成为站点架构的一部分。”
“各种编辑器都非常适合本地数据模型和基于 SPA 的架构，以支持对其进行修改。然而，这些系统的普遍复杂性确保了性能仍然是一个持续的斗争。因此，以这种风格构建应用程序的团队应该考虑强大的性能护栏，预先确定关键的用户旅程，并确保仪表到位，以避免令人不快的性能意外。”
“这是因为，在我的价值 3000 美元的笔记本电脑上进行的与 NPM 一起开发的主要结果是导致团队比任何人预期更快地陷入困境。 ”
“……它适用于 Facebook”
从统计学的角度来看，Facebook 并不是你创造的。你的问题可能看起来与 Facebook 2010 年代初的问题完全不同，即使它们确实如此，跟随他们的领导也是一个糟糕的主意。”
“React 知识也不是特别有价值。任何熟悉 React 的...巴洛克...惯例的团队都可以轻松掌握 Preact、Stencil、Svelte、Lit、FAST、Qwik 或任何一种更快、更小、反应性更强、需要更少脑力记账的客户端系统。”
“......英雄们将为你的产品带来令人难以置信的好处，而解决下一个问题的成本只是 React 社区最终承认框架主义本身造成的一小部分。”
“那些已经掌握了 useMemo 的可怕之处的人和朋友们无法接受 DOM 生命周期方法或事件循环或现代 CSS 的想法是侮辱性的。这是不公平的侮辱并限制了组织的潜力。”
“‘...React 是行业标准’
这充其量只是一部令人安慰的小说。”
“在 100 多个咨询项目中，我从未见过两个相同的 React 设置可以保存较小的情况，其中开发人员尚未添加 Create React App 的默认设置（多年来，它本身发生了巨大的变化，最终被从React 文档是最好的入门方式）。”
“...如果你不介意我问一下，“CSS-in-JS”冒险进展如何？仍在编写类组件，或者您是否有一个仍然令人头痛的强制（部分）迁移？”
“...将 NPM 依赖性视为一种由未来工程能力抵押的高息债务。”
“使用 Next.js 构建的网站的性能比 11ty、Astro 等 HTML 优先系统的网站要差。”
Lautaro Andreani 在 Unsplash 上的照片
以上是React 的严酷现实：Alex Russell 的必读见解的详细内容。更多信息请关注PHP中文网其他相关文章！
