React 毁了 Web 开发（转载）

本文并不是为了引发争论或者让大家非要争一个好坏。我仔细阅读该文章之后，发现里面提出的问题是我们常常忽视并且对于构建可持续项目发展的非常重要的问题。

不论是小兵还是leader都应该持续的去注重这些东西。

以下是正文翻译：原文来自：medium.com/building-pr…

以下为译文：

React 是一个很好的库，对于 Web 开发很重要，因为它引入了声明式与反应式模板，这在当时是每个人都需要的范式转变。当时（也就是 6～7 年前），我们面临着需要的范式转变的问题，而 React 很好地解决了这个问题。

另外提一句，在 React 之前，Ember 也解决了同样的问题。然而，它的性能并不那么好，而且该框架规定了太多东西，远不如 React。

然而，React 在开始流行之后，发展变得一团糟。React 社区中开启了一种新趋势，一切都围绕着炒作、新奇和创造新范式的转变。每隔几个月就会涌现一些新的库，为我们应该如何编写 React Web 应用程序设定新标准，同时还会解决大部分已经解决的问题。

下面，我们以 " 状态管理 " 为例来说明。由于 React 缺少传统的依赖注入系统（DI 是通过组件组合实现的），所以社区不得不自己解决这个问题。然而，后来就变成了一遍又一遍地解决这个问题，每年都会带来一套新的标准。

React 只是一个渲染引擎，在常见的 Web 应用程序中，你需要使用很多库来构建项目的框架，例如数据层、状态管理、路由、资产捆绑器等。

React 背后的生态系统给了你太多这样的选择，而这个技术栈也因此而变得支离破碎，并引发了著名的 "Javascript 疲劳 "。

此外，还涌现了一种趋势：" 框架比较热潮 "。各个 JS 框架之间经常会展开渲染速度以及内存占用等属性的比较。其实，这些因素在大多数情况下根本无关紧要，因为应用的速度缓慢并不是由于 JS 框架的速度过慢而引起的，而是因为糟糕的代码。

然而，就像世界上所有的趋势一样，这个趋势有点过，甚至危及了新一代的 Web 开发人员。我就在想，为什么一个库能成为 Web 开发人员简历中最耀眼的技术？更糟糕的是，它甚至算不上一个库，只不过是库中的一个模块。人们常常将 React hook 视为一项 " 技术 "，甚至可以与代码重构或代码审查等实际技术相提并论。

认真地说，我们什么时候才能停止吹捧这种技术？

比如说，你为什么不告诉我，你知道：

如何编写简单易读的代码

不要向我炫耀你掌握了某个 GitHub 上获得星星数最多的库；而是给我展示一两个优秀的代码片段。

如何管理状态

不要讨论某个流行的状态管理库，而是告诉我为什么 " 数据应该下降而动作应该上升 "。或者说，为什么应该在创建的地方修改状态，而不是组件层次结构中更深的地方。

如何测试代码

不要告诉我你知道 Jest 或 QUnit，而是解释一下为什么很难自动化端到端的测试，以及为什么最低程度的渲染测试只需付出 10% 的努力，却能带来 90% 的好处。

如何发布代码

不要告诉我你使用 CI/CD（因为如今每个项目里的成员都不止一个人），而是解释为什么部署和发布应该分离，这样新功能就不会影响到已有功能，而且还可以远程启动新功能。

如何编写可审查的代码

不要说你是一名 " 团队成员 "，而是告诉我代码审查对审查者来说同样困难，而且你知道如何优化 PR 才能提高可读性和清晰度。

如何建立稳固的项目标准

除非团队中只有你一个人，否则你就必须遵守项目中的标准和惯例。你应该告诉我命名很难，而且变量的范围越广，投入到命名中的时间就应该越多。

如何审核别人的代码

因为代码审查可确保产品质量、减少 bug 和技术债务、共同建立团队知识等等，但前提是将代码审核贯彻到底。代码审查不应该只是自上而下的活动。对于经验不足的团队成员来说，这是一个很好的学习机制。

如何在 JS 框架中找到自己的方式

这与 GitHub 上的星星数量无关，你应该学习如今大多数 JS 框架都拥有的共同原则。了解其他框架的优缺点可以让你更好地了解自己选择的框架。

如何建立最小化可行产品

技术只是制造产品的工具，而不是流程。与其将时间浪费在技术争论上，还不如花点时间优化流程。

如何优化：不要太早，也不要太晚

因为在大多数情况下根本不需要优化。

如何结对编程

因为结对编程与代码审查一样，这是最重要的共享知识和建立团队凝聚力的实践。而且也很有意思！

如何持续重构

因为每个项目都有技术债务，你应该停止抱怨，并开始重构。每次开发新功能之前都应该进行小型代码重构。大规模的重构和重写永远不会有好结果。

以上就是我认为 React 毁了 Web 开发的原因。很多人对这一说法很感兴趣，并热切地加入了辩论。