真的有人喜欢 React 吗？

# JSX.lol 来源：https://jsx.lol/ ### 终结 (https://www.focalcurve.com/journal/the-end/) > 以我的经验来看，React（及其同类）几乎总是错误的解决方案。我相信React有其用武之地，但它已经变成了那柄传说中的锤子，让一切看起来都像钉子。我也知道React可以被用得不错，但似乎几乎从未有过。 ### JS 密集型方法与长期性能目标不兼容 (https://sgom.es/posts/2026-02-13-js-heavy-approaches-are-not-compatible-with-long-term-performance-goals/) > 实际上，对于任何规模尚可的 JS 密集型项目，你应该预料到：你构建的东西会比宣传的慢，随着持续开发它会越来越慢，而且开发和维护（尤其是维护）所需的工作量比你被引导相信的要多，bug 数量也和其他方法一样多。 ### React Server Components 中的严重安全漏洞 (https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components) > 11月29日，Lachlan Davidson 报告了 React 中的一个安全漏洞，该漏洞允许未经身份验证的远程代码执行 [...] 此漏洞被披露为 CVE-2025-55182，CVSS 评分为 10.0。 ### 为何使用 React？(https://adactio.com/journal/22265) > 默认情况下，你会得到可怕的注水模式——在服务器上用 JavaScript 完成所有计算（耶！），立刻提供 HTML（耶！耶！）……然后提供所有服务器上已经有的同一套 JavaScript（呃——等等，什么？）。 ### 我用 10 种方式构建了同一个应用：评估移动端性能的框架 (https://www.lorenstew.art/blog/10-kanban-boards/) > React 的移动端策略本质上将团队推向平台锁定。Web 提供了另一种选择：没有守门人，没有平台费用，直接分发。 ### 是时候监管 React 了吗？(https://dbushell.com/2025/10/23/react-regulation/) > React 的核心失败被混乱的 API 设计进一步加剧，这种设计导致文档犹豫不决，需要撰写论文来解释，且正确的用法被无止境地争论。 ### React 凭默认赢得胜利——而这正在扼杀前端创新 (https://www.lorenstew.art/blog/react-won-by-default/) > 当团队需要一个新的前端时，对话很少从“约束条件是什么，哪种工具最适合它们？”开始。它常常从“我们用 React 吧；所有人都懂 React”开始。这种条件反射创造了一个自我延续的循环，在此循环中，是网络效应而非技术适配度决定了架构。 ### React 博文：反思与反应 (https://mbrizic.com/blog/react-ii/) > 将整个问题斥为“技能问题”，并暗示因为一个外部库解决了 React 本会允许你解决的问题所以一切安好——这让我感到非常奇怪。[...] 你会认为，三年后回到一项技术时，你仍然能够继续在上面工作——我是说，它能变多少？在任何其他技术栈中，这可能是真的，但在前端开发中，尤其是 React——认为可以这样太天真了。 ### 科技创始人？企业家？这就是为什么你应避免在应用中使用 React.js (https://medium.com/@fourtyeighthours/tech-founder-entrepreneur-this-is-why-you-should-avoid-react-js-in-your-app-41fe9fb7511b) > React 不仅慢——它是一个臃肿的生态系统，技术债务深植于其 DNA 之中。然而尽管如此，它仍然被选择。为什么？ ### React 仍然让人感觉疯狂，而且没有人谈论它 (https://mbrizic.com/blog/react-is-insane/) > 很容易简单地说 React 就是非常疯狂，然后继续我们的生活。但作为理性的灵长类动物，我相信我们可以做得更好。我们可以尝试去理解它。 ### 大会、清晰度和烟雾弹 (https://infrequently.org/2025/06/conferences-clarity-and-smokescreens/) > 我日常的咨询工作，以及高知名度的行业数据表明，React 社区深陷一场深刻且可测量的质量危机。但 React Summit 的与会者如果事先不知道，就不会听说这件事。 ### Next.js 15.1+ 在 Vercel 之外无法使用 (https://omarabid.com/nextjs-vercel) > Next.js 已经变成了一个伪装成开源框架的 Vercel 供应商锁定。为了你自己好，在为你的“下一个”项目选择其他东西时，省省头疼。 ### 为什么硅谷 CTO 们正秘密地远离 React (https://freedium.cfd/https://javascript.plainenglish.io/why-silicon-valley-ctos-are-secretly-moving-away-from-react-bdf64f0b6072) > 几位 CTO 提到了一个令人惊讶的问题：虽然 React 开发者很多，但真正有技能、理解深层模式的开发者越来越稀少且昂贵。[...] 几家公司报告说，他们最有经验的工程师对日益增长的复杂性感到沮丧，转而投奔使用其他技术的岗位。 ### HTML 比 React 更好！？(https://gomakethings.com/html-is-better-than-react/) > [...] 在 JS 可用时逐步增强的基线 HTML... 1. 在过程中更早地给人们提供更可用的体验。2. 确保在慢速连接上，你的网站不会显得像垃圾。3. 意味着如果出了问题，人们仍然可以使用你的网站。 ### 在选择 Next.js 之前你应该知道这些 (https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/) > 上周末，Vercel 披露了 Next.js 的一个严重安全漏洞。这类问题很正常，但 Vercel 选择处理它的方式如此糟糕、草率且不尊重社区，这加剧了我对项目治理的担忧。 ### 停止使用和推荐 React (https://blog.lusito.info/stop-using-and-recommending-react.html) > 我已经使用 React 很久了。请相信我：没有任何理由使用它，反而有很多理由反对它。 ### 从 React 迁移一年后 (https://kellysutton.com/2025/01/18/moving-on-from-react-a-year-later.html) > 也许是因为利率变化或政治风向，但我认为“胖客户端”时代的 JS 密集型前端正在退出舞台。围绕边缘应用的炒作是被误导且不必要的，对于许多不同类型的成功企业而言。没有 JavaScript，很多交互是不可能的，但这并不意味着我们应该试图编写超过必要数量的 JS。 ### 如果不是 React，那是什么？(https://infrequently.org/2024/11/if-not-react-then-what/) > 框架主义鼓吹改善用户体验的方式是在框架生态系统中采用更多（或不同的）工具。这为信徒们提供了看起来像工程活动的事情去做，但实际上并不是。它甚至可以成为一种全面性的承诺；框架主义者无法获取框架扩展宇宙之外的用户问题解决方案。 ### 我没有时间学习 React (https://www.keithcirkel.co.uk/i-dont-have-time-to-learn-react/) > React 支持者可能会声称 React 会教你现代 UI，但据我所知，它几乎无法应对现代 UI。autofocus 是坏的，自定义元素在除实验性版本之外的所有版本中都无法工作，使用任何“现代”功能如 dialog 或 popovers 都需要 useEffect，而合成事件系统几乎没教给你 DOM 实际如何工作。这不是现代 UI，这是 2013 年初创时的 UI。 ### 里氏替换之枪：React 和 Web Components 的并行演化 (https://www.baldurbjarnason.com/2024/liskovs-gun/) > React 已经变成了一个臃肿的躯壳，满是虚假承诺、误导性声明和无尽的向后兼容层级——而且是错误类型的向后兼容，因为它们在更新时仍然偶尔会搞坏你的代码。 ### 如何使用 HTML 框架仅用一行代码构建计数器组件 (https://scottjehl.com/posts/how-to-build-a-counter-component-using-the-html-framework-in-just-1-line-of-code/) > 找到你的 /node_modules 文件夹，把它拖到垃圾桶里。 ### 永不结束的故事 (https://garrettdimon.com/journal/posts/the-neverending-story) > Applets。ActiveX。Flash。Flex。Silverlight。Angular。React。许多公司都认为他们懂得更多，但却未能看到更大的图景。 ### 什么是 React.js？(https://briefs.video/videos/what-is-react/) > 它的支持者可能很奇怪，它把自己看得太严肃，它的文档冗长无味。这些是某些人描述基督教的方式。这个视频是关于 React.js 的。 ### 清算：第四部分——出路 (https://infrequently.org/2024/08/the-way-out/) > 拒绝同意构建 YAJSD（又一个 JavaScript 灾难）的计划。工程领导者依赖他们的高级工程师提供关于采用何种技术的可信指导。当有人不可避免地提出 React 重写时，不要保持沉默。 ### 经过十年的 React，前端现在进入后 React 时代了吗？(https://thenewstack.io/after-a-decade-of-react-is-frontend-a-post-react-world-now/) > 如果你是一名刚进入这个行业的新 Web 开发者，你甚至可以考虑完全避开 React——虽然不可否认这会减少你的短期就业前景。但这至少是一个值得认真考虑的选择，甚至可能帮你找到一家有前瞻性的雇主的工作。 ### 从 React 转向原生 DOM API：一个真实世界的例子 (https://thenewstack.io/pivoting-from-react-to-native-dom-apis-a-real-world-example/) > 一个开发团队从 React 的“压倒性的 VDOM”转向了现代 DOM API。他们立刻看到了速度和交互的改进。 ### React 19（几乎）让互联网变慢了 (https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/) > 在经历了大量的公众反对、激烈讨论以及可能很多幕后沟通之后，React 团队退出并决定暂时搁置这一改变。 ### 一个更快的 Microsoft Edge (https://toot.cafe/@slightlyoff/112521248529973776) > 从 React 转向现代 Web Components + HTML 优先架构，对用户，特别是低端硬件用户，带来了巨大的好处。 ### React、Electron 和 LLM 有一个共同目的：开发者工具流行度的劳动力套利理论 (https://www.baldurbjarnason.com/2024/react-electron-llms-labour-arbitrage/) > 对于绝大多数构建面向 Web 软件的组织来说，React 客观上比许多替代方案更差。 ### 我们在三周内将 React 应用重写为 Svelte (https://dusty.phillips.codes/2024/03/20/we-rewrote-our-react-app-in-svelte-in-three-weeks/) > 我看到过所有那些关于 Svelte 是“最受喜爱”框架的标题，然后……我承认，我只是把它们当作噪音忽略了。但下次调查来临时，我会和他们一起，在 Svelte 的乐队花车上挥手。 ### 感觉 React 最近开始挨骂了 (https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/) > 我谈论了社区中对 React 态度的明显转变，并就你项目的决策制定给出了一些建议。 ### 转换成本 (https://adactio.com/journal/20837) > 个人而言，我希望更多人抱怨客户端 React 带来的糟糕用户体验。然而，抱怨却普遍集中在开发者体验上。 ### 移除 React 只是从你的代码库中消除弱点 (https://begin.com/blog/posts/2024-01-26-removing-react-is-just-weakness-leaving-your-codebase) > 通过摆脱 React 和其他重量级框架的折腾，加倍投入 Web 基础，你将为你的职业生涯和代码库都做好面向未来的准备。 ### 拼接文本 (https://johan.hal.se/wrote/2024/01/24/concatenating-text/) > 为什么大家一遇到屏幕上需要更新的东西就立刻伸手去拿 React？为什么我们坚持把我们的前端关注点与后端关注点混在一起？ ### React，你要去哪里？(https://dev.to/matfrana/react-where-are-you-going-5284) > 然而，今天我看到了两个让我对 React 不那么喜欢的问题，也让担心新开发者可能会被它吓到：所有权和复杂性。 ### 告别 React (https://kellysutton.com/2024/01/15/moving-on-from-react.html) > 在 2023 年 React 的假启动之后，我们现在使用的是一个我们不会与之对抗、更能映射到客户领域的技术栈。 ### 对 React 有点恼火 (https://blog.cassidoo.co/post/annoyed-at-react/) > [...] 当我想要构建稍微复杂的东西时，我仍然会伸手去拿 React，只是……我希望我在这样做的时候能更开心一点。 ### 对 React 发布状态越来越不满 (https://macwright.com/2024/01/03/miffed-about-react) > 距离上次 React 发布已经一年半了，这比以往任何一次发布间隔都要长得多。 ### React Server Components：优点、缺点和丑陋之处 (https://www.mayank.co/blog/react-server-components/) > 与此同时，React 除了在 2019 年进行了一次被放弃的实验外，没有做任何事情来改善其可怜的客户端方案。它是一个为解决 Facebook 规模的问题、使用 Facebook 规模的资源而创建的遗留框架，因此对于大多数用例来说并不合适。 ### 替换 React：Liveview 如何解决我们的性能问题 (https://www.youtube.com/watch?v=Qz0ZnOMaePo) > React SPA 的性能挑战创造了探索 Liveview 的机会。经过两天的探索，我们相信 Liveview 提供了前进的道路，并且在几周内，我们用 Liveview 替换了我们的 React SPA。 ### 请不要使用 React (https://dev.to/borfast/please-dont-use-react-16m4) > 你应该停止使用 React。事实上，你可能根本就不应该在你使用过它的任何项目中使用它。但在你掏出锯短的猎枪朝我开火之前，请听我说完。 ### 为什么 Signals 比 React Hooks 更好 (https://www.youtube.com/watch?v=SO8lBVWF2Y8) > React 中的 Hooks 难以正确使用，更难以高性能地使用。这导致许多应用程序代码质量差、性能不佳，但这种情况不再必然如此。 ### React Server Components 是一个糟糕的选择（用于发布）(https://www.youtube.com/watch?v=dH6_cJwgHnM) > 论证如果你想快速发布应用程序，你不应该使用 React Server Components。如果你想学习、实验或制作内容，那当然可以！ ### 只有我觉得 React 的方向错了吗？(https://old.reddit.com/r/reactjs/comments/13n9zny/am_i_the_only_one_that_thinks_that_the_direction/) > 感觉 React 在按自己的规则玩自己的游戏。 ### 客户端 JavaScript 和 React 批评：接下来会发生什么？(https://molily.de/javascript-criticism/) > 我们如何改进 JavaScript 的使用，教授渐进增强并调和社区？ ### React 批评历史参考 (https://www.zachleat.com/web/react-criticism/) > 多年来，对 React 项目提出了许多批评，其中一些已经得到处理，而另一些仍然在风中摇曳。