什么项目需要 React？ 这是 Chris Coyier 在 最近的一篇博文中 谈到的问题。 我非常喜欢 Chris 的文章，所以我很想知道他对这个问题的看法。
简而言之，Chris 列举了一系列使用 React（或其他类似的现代 JavaScript 库）进行项目开发的优缺点。 虽然我并不反对他的论点，但我还是得出了不同的结论。
所以今天，我来谈谈“什么项目需要 React？” 这个问题的答案不是“视情况而定”。 而是“每次都需要”。
React 与 Vue 与 Angular 与…
首先，我们先澄清一下：在 Chris 的文章中，他将 React 作为“前端库”的代表，我在这里也这么做。 另外，React 是我在 VulcanJS （一个 React 和 GraphQL 框架）的持续工作中最熟悉的库。
也就是说，我的论点应该同样适用于任何提供与 React 相同功能的其他库。
锤子的力量
当你只有锤子时，所有东西看起来都像是钉子。
这句谚语长期以来一直用来谴责任何试图对每个问题采用系统性的“一刀切”方法的人。
但让我们假设一下，你确实生活在一个充满钉子的世界里（尽管这听起来可能不舒服），并且你那把可靠的锤子能够解决你遇到的任何问题。
只要考虑一下能够每次都重复使用相同的工具 的好处。
- 不用花时间决定使用哪个工具。
- 少花时间学习新的工具。
- 更多时间练习你选择的工具。
那么 React 是那个工具吗？ 我认为有可能！
复杂度谱
首先，让我们解决反对“React 全方位覆盖！” 观点的最常见论点。 我将直接引用 Chris 的话。
例如，一个博客可能没有出现会使 React 成为合适选择的任何问题，也符合任何场景。 由于它不适合，因此它可能不适合，因为它为不需要它的东西引入了复杂的技术和依赖项。
说得有道理。 一个简单的博客不需要 React。 毕竟，即使你确实需要一点 JavaScript 来连接新闻稿订阅表单，你也可以直接使用 jQuery。
什么？ 你需要在不同页面上的多个地方使用该表单？ 并且只在特定条件下显示？ 还要进行动画处理？ 等等，等等…
我试图用这个小场景说明的是，复杂度不是一个非此即彼的二元选择。 相反，现代网站存在于一个从静态页面一直到丰富的单页应用程序的连续谱线上。
所以，也许你的项目现在舒适地嵌套在“简单”的频谱一端，但六个月后会怎么样？ 选择一个让你有成长空间的技术难道不是比选择一个将你局限于不良实践的技术更好吗？
React 的优势
过早优化是万恶之源。
程序员之间流传的另一句名言。 毕竟，当胶带可以很好地完成工作时，谁需要锤子和钉子！
但这假定“过早优化”是一个漫长而艰苦的过程，几乎没有好处。 我认为这并不适用于 React。
虽然 React 可能需要一段时间才能适应，但一旦你学会了 它的基本概念，你就会像使用经典前端工具一样高效。
实际上可能更高效，因为 React 利用了极其强大的组件概念。 就像 CSS 鼓励你以可重用的类和样式进行思考一样，React 推动你转向一种灵活的、模块化的前端架构，它对每个用例都有好处，从简单的静态主页到交互式后端仪表板。
JavaScript，无处不在
我们生活在一个 JavaScript 世界里。 或者，正如 Chris 所说
你在服务器端有 Node.js。 有很多项目将 CSS 从混合中剔除，并通过 JavaScript 处理样式。 并且使用 React，你的 HTML 也在 JavaScript 中。
所有 JavaScript！ 万岁 JavaScript！
Chris 并不完全信服，但我信服。 JavaScript 本身并不一定是完美的，但能够访问整个现代 NPM 生态系统非常棒。
安装 jQuery 插件过去需要找到其主页、下载它、将其复制到你的项目目录中、添加一个 <script> 标签，然后希望记得每隔几个月检查一下是否有新版本。 现在，将同一个插件作为 React 包安装只需一个简单的 npm install 命令即可。
有了像 styled-components 这样的新库，甚至 CSS 也正在被拖入未来。
相信我，一旦你习惯了这个所有东西都使用相同语言的世界，你很难再回到过去的方式。
有人会为用户着想吗！
我知道你在想什么：到目前为止，我一直试图向你推销 React 对开发人员的好处，但我一直谨慎地避开任何关于最终用户体验的提及。
这仍然是反对现代库的关键论点：缓慢的、臃肿的 JavaScript 网站，即使是显示单个“一个奇怪的技巧”广告也要花费很长时间。
但这里有一个小秘密：你可以在完全没有 JavaScript 的情况下获得 React 的所有好处！
我在这里说的是在服务器端渲染 React。 实际上，像 Gatsby （以及即将发布的 Next.js）这样的工具甚至允许你将 React 组件编译成静态 HTML 文件，你可以将这些文件托管在例如 GitHub 页面上。
例如，我自己的个人网站 是一个 Gatsby 生成的 React 应用程序，它完全不加载任何 JavaScript（除了 Google Analytics 代码片段）。 我得到了使用 React 进行开发的所有好处（全 JavaScript、访问 NPM 生态系统、styled-components 等等），但最终得到一个 100% 的 HTML 和 CSS 最终产品。
总结
概括地说，以下是我认为 React 是任何项目都可行的选择的四个原因。
- 真的很难保证你永远不会需要像选项卡、表单等交互式功能，即使是最简单的网站也是如此。
- React 的基于组件的方法即使对于静态内容网站也有很大的好处。
- 访问现代 JavaScript 生态系统是一个巨大的优势。
- 现代服务器端渲染工具消除了使用 React 对最终用户造成的不利影响。
那么，Chris，你怎么看？ 我说服你了吗？ 或者你心中仍然存在疑问？
亲爱的读者，你怎么看？ 无论你像 Chris 一样认为每个工具都有其用途，还是你像我一样同意锤子的时代已经到来，请在评论中告诉我们！
致敬JavaScript！听起来就像“致敬九头蛇”！而我站在神盾局这边
我看到很多人都采用你的方法，但却没有承认。所以，我为你鼓掌。
我以前也采用过这种方法，但我已经学会了更多地投资于问题领域，而不是框架/工具集，因为它们就像风一样来去匆匆。
祝VulcanJs好运！
热烈的辩论！
在我开始之前，请允许我说明我不是React所有事物的专家。我是一个新手，但我拥有十年作为技术专家和React生产产品的产品负责人的视角。
我认为这篇文章的论点可能更像React Native，当你选择React这条路时，它会为你打开一些门（比如原生应用），而你可能不会在其他技术栈中获得这些门。所以我认为，这是你要添加到论据中的另一件事。
我们也可以抛开任何关于SEO、渐进增强、用户体验等的论点，因为React应用可以在服务器上渲染，因此我们可以拥有健康的URL，也不会有人被排除在外等等。
或者我们真的可以吗？对于你的博客来说，服务器渲染的页面可能很棒，但我认为，不能断言这意味着你根本不需要发送任何客户端JavaScript。我认为99%的React使用都是专门针对前端的。正是所有这些状态管理（响应客户端事件）和DOM管理让React在最初的时候如此吸引人，而我也会很乐意让人们使用React来处理这些。所以说“你可以在没有任何JavaScript的情况下获得React的所有好处！”对我来说感觉不太对劲。
我很难理解一个服务器渲染的React应用是什么样的，它也在前端利用了所有React的功能。我想这就是为什么Ember将他们的版本称为“fastboot”吧，因为你是在发送页面，但它在JavaScript到达并执行之前基本上是不可用的。感知性能。
复杂性也是一个因素。在以下两者之间存在着很大的区别：
React
以及
React + Redux*
（*替换你最喜欢的状态管理系统）我认为Redux是一个非常重要的部分，如果目标是避免意大利面条代码和数据源之间的不一致。
这与以下两者之间的区别也很大：
React + Redux + Immutable + Styled Components + Babel + Webpack + Lambda + DynamoDB
所有这些东西都提供了很多价值，并且在很多情况下都有意义。但老天爷啊，这确实是一个厚厚的技术栈。
你没有提倡这一点，但即使是使用Gatsby，你也在使用：
React + Gatsby + Webpack + React Router + 服务器端渲染
这是一个不小的负担。
我并没有想表达什么巨大的观点，只是想说走这条路意味着巨大的学习曲线和大量的依赖。我希望在选择过程中能够做出一些能让用户轻松退出（切换到未来的热门技术栈）的选择。例如使用Markdown中的内容和CSS。
但你也可以说任何技术栈都有这些问题。
让我们来讨论这四个要点！
我不认为是“交互式功能”需要React。尤其是少数几个，比如标签和（即使是重复的）表单。我认为是一大堆相互交织的交互式功能，指明了“选择React”的时刻。
如果最终产品是“基于静态内容的网站”，我会说，可以尝试各种技术栈。一切都取决于你的选择。传统的CMS、静态站点生成器、使用Pug或Nunjucks等工具编译的网站，当然，一些很酷的无头CMS + 服务器渲染的React应用可能很完美。
我很难认为“静态内容网站？最好的选择是服务器渲染的React”。这个技术栈非常厚重和固执己见，我不确定每个这样的网站都是一个适用于比喻意义上的唯一真锤子的钉子。
同意！具体来说，React并不是必须的，但我理解你的意思。
就快速启动情况而言，当然。这有助于提高加载速度，因此减轻了缓慢的负面影响。就传统的渐进增强理念而言，不是的。如果你有一个由React驱动的动画和交互式表单，你需要在客户端使用React来驱动它，我认为，React并没有鼓励你让服务器渲染的表单在客户端React无法正常运行时也能正常工作。
我很享受这场讨论！谢谢你的观点，Sacha。
很棒的辩论！只是想反驳一点
由于Gatsby负责你的Webpack配置、路由以及SSR，实际上Gatsby技术栈就是React和Gatsby。我认为这就是人们对React有很多误解的原因，不熟悉JavaScript生态系统的人会认为Webpack、Babel等都是你必须学习的独立技术栈部分，而实际上它们可以只是在后台运行并改善开发人员体验的工具。
但总的来说，我认为你提出了一些非常合理的观点，这使得很难反驳你... 不过，我还是尽力了；)
在一个非常复杂的话题上，却给出了非黑即白的建议...
我认为，这些论点中经常缺失的，也是这些论点中经常缺失的，是背景信息，尤其是所做的假设。我们处理的项目种类繁多，它们经常需要不同的工具，但有时很难跳出自己的世界，看到别人的世界。我经常发现，当我与客户端的布道者交谈时，我总是会立即不同意他们的观点，但当我深入挖掘时，我发现他们所做的工作往往非常适合JavaScript密集型的项目，而我每天所做的工作则不然。
也许这些例子并不恰当，但表单的历史比JavaScript更久远，完全没有必要在简单的表单上使用任何JS。在现代浏览器中，标签也可以很容易地在没有JS的情况下完成。没有额外的背景信息就提出这样的论点，会导致新手开发者毫不犹豫地接受它，在我看来，这会导致网络素养和整体理解力的下降，对于现在学习网络编程的开发者来说更是如此。
我在这篇文章中故意选择了一个有争议的观点，所以我会继续保持这个风格；)
我认为这其实是一件好事。网络开发已经变得过于混乱和复杂，我们已经习惯了，所以没有意识到这一点。当然，你可以使用单选按钮和CSS选择器来构建标签，但这算是一种合理的方式吗？我们难道不是在10年前就抗议过滥用表格进行布局吗？
这就是我相信React（或类似的东西）及时出现作为HTML/CSS之上的抽象层，让所有除了少数网络开发人员以外的人都能让所有这些“网络素养”过时的原因。
Sacha，这是一个非常有效的观点，我同意。然而，阅读你的文章，我更多地感受到了一种争论性的信息，而不是赋能性的信息。
我想从中学到的是，React，就像WordPress一样，应该是一个任何新手开发者都能毫无顾虑地使用的工具，而不必担心“这真的是正确的工具吗？”这样的问题。如果你继续深入网络开发，它同样是一个很好的选择，但你也要知道，还有很多其他的选择。
让我们停止争论，开始鼓励更多人去创建更多酷炫的东西。
你能帮助我们理解这场辩论中的动机和可能的利益冲突吗？审查“外部”文章的通常方法是包含可能存在利益冲突的声明（通常在文章末尾）。Chris我知道，Sacha我不了解。是否存在与所讨论的产品以及论点作者相关的任何关系（工作、金钱或其他方面）？请帮助我们了解类似这些文章中潜在的偏差。谢谢。
我第一次阅读时没有注意到“vulcanJS”的引用，但仍然不清楚它与React的关系是什么——也许这篇文章不是针对不使用该产品的人？（还）
我认为Yeogurt是简单的静态网站的最佳选择。它为进行模块化设计提供了一个很好的框架，还让你能够轻松地访问npm社区。
谢谢Chris解释了更大的依赖技术栈，当你开始使用React时，可能会遇到这些技术栈。我毫不怀疑React非常强大，网络开发者应该尝试学习它。然而，我总是对投资那些你并不一定“掌握”的技术持谨慎态度。例如，我看到很多项目不必要地、出于习惯地导入库。底线是——了解你使用的技术，什么时候使用它以及为什么使用它。我同时也提倡用你的大脑来解决问题，而不是仅仅导入一个预先构建的组件——有时尝试从头开始构建一些东西，并从第一性原理中真正学到一些东西，而不是仅仅学习如何将技术组件链接在一起或混搭在一起以获得你需要的结果，感觉会更好。
这篇文章引起了很多反驳，但从我的角度来看（小型代理公司，服务于中小客户），React非常有用，因为客户总是希望在项目成熟的过程中不断添加新功能，而不是倒退。
例如，如果我们从一个只需要静态网站但可能以后会想要做应用程序的客户开始，直接使用 React 意味着以后的工作量更少。
另外，使用 React 真的很有趣。我现在做的一切都非常 DRY，我终于可以专注于有趣的事情，而不是整天感觉自己在敲代码，如果学习曲线看起来太陡峭，可以试试 react create app - 它开箱即用。
这是一个很棒的观点，谢谢！
我不认为 React 等同于“锤子”。锤子是一种基本的工具，已经存在了数千年，并且肯定还会继续使用很多年。在 Web 世界中，类似的东西将是 HTML、CSS 和（纯）Javascript - 已经存在很长时间并且将继续存在很长时间的标准化技术。
React（及其同行）是一种更复杂的工具，它没有经受住时间的考验。很可能在几年内，使用 React 将被认为是不酷的，开发速度也会放缓。今天使用 React 的人最终将不得不转向其他东西。
我不反对 React 和其他类似的框架，但是这些工具是为解决我们这个时代中的特定问题而创建的，它们不应该被用作逃避学习核心技术的借口。
React 是一种类似于 JQuery 曾经是什么的工具，或者像 WYSISYG 编辑器在更久远的过去是什么。如果您是 Web 开发人员，那么您应该掌握 Web 的核心技术，并且不应将当下的流行趋势作为逃避学习的借口。然后，您可以在对特定项目有意义时使用 React 等，而不是因为它是您唯一熟练的工具。
我完全同意 Theo。
我喜欢你的东西 Sacha，我感谢你在这里采用了一种非常有偏见的观点来阐明你的观点，但我想要提到一些我自己也持异议的观点，或者是我自己在实践中发现的问题。
这条评论出现在关于添加新闻稿订阅表单的句子末尾，假设需要 jQuery 来使其工作并对其进行动画处理。我们完全可以使用新闻稿订阅表单和动画，而无需使用 jQuery 或 Javascript，但是，你确实说对了，某些条件可以通过 React 的帮助来更轻松地实现。
另外，我们正在使用的技术是 HTML、CSS 和 Javascript，所以这里也没有什么限制。
虽然这听起来很棒，但首先要设置 NPM，而且如果出现问题，就要小心了。有时，去主页获取最新稳定版本的库比设置 npm 并与你的项目一起运行更容易。
再次强调，我知道你在这里想表达一个观点。我渴望比现在更深入地了解 React，但人们不应该误以为它是构建所有网站的最简单方法。
继续努力，Sacha！