一些有趣的文章正在流行
我喜欢 Tom 的观点，React（他将其作为 JavaScript 框架的代表）有其理想的使用场景
React 的最佳应用场景是中等交互的界面。需要即时反馈的复杂表单，需要移动并立即响应的 UI。这就是 React 的优势所在。
如果我对网页设计和开发领域有任何期望，那就是我们能够更好地选择 适合工作的工具。
我听到很多人强调这一点
例如，我可以保证，这个博客比任何 Gatsby 博客都要快（并且非常感谢 Gatsby 团队），因为 React 静态网站无法做到比非 React 静态网站更快的速度。
一种反应是“当然”。React 是一堆 JavaScript，它做很多事情，但不提供让网页比没有 React 情况下更快的超能力。另一种反应是：“事实上，它确实可以”。这就是 SPA 的核心：无需重新加载页面。相反，我们可以针对新页面所需的新的数据发送一个精简的网络请求，并仅重新渲染必要的元素。
Rich 进一步深入探讨了这一点
当我点击 Tom 的无 JS 网站上的链接时，浏览器首先等待确认这是一个点击，而不是刷卡/滑动，然后发出请求，然后我们必须等待响应。对于具有客户端路由的框架构建的网站，我们可以开始做更多有趣的事情。我们可以根据分析数据对用户可能交互的操作做出有根据的猜测，并为他们预加载逻辑和数据。我们可以从用户第一次触碰（或悬停）链接时就开始请求，而不是等待点击确认 - 最坏的情况是，我们加载了一些东西，如果他们确实点击了，这些东西将在稍后有用。我们可以提供更好的视觉反馈，表明正在加载并即将进行转换。而且我们不需要加载页面的所有内容 - 通常，我们可以使用一小段 JSON，因为我们已经有了该页面的 JavaScript。这些东西很难手动完成。
这就是这些东西很容易引起争论的原因。每个人都有自己的观点。当我们试图代表整个网页说话时，我们很难达成一致。但是，网页太大，无法进行笼统的概括。
人们是否过度依赖 React 驱动的 SPA？可能，但并非没有道理。那里存在吸引人们的创新。问题是，我们如何改进它？
从前端的角度来看，像 React 这样的前端框架鼓励要求我们以组件的方式编写前端，本身就很有吸引力。
这两篇文章都表达了乐观和悲观的情绪。这两篇文章的结尾句截然不同。
使用合适的工具很好，但网页开发者不想每隔几个月就学习一门新的语言、框架或数据库。
是的，有时我们会使用 React 和 CMS 来创建一个网站，而使用静态网站生成器可能更快。有时，我们可能会使用 jQuery 构建一些东西，而实际上存在更好/更新的替代方案，有时我们可能会选择构建一个 REST API，而 GraphQL 更适合，或者安装 SASS 来执行一些非常简单的 CSS。
关键是我们希望在多个项目中使用相同的技术栈，因为我们希望有机会精通它。
我们不想在每个新项目中都从一堆书籍开始，或者浏览 GitHub 和 Stack Overflow，只是为了在进行任何实际工作之前掌握基础知识。
我当前的栈是 React，使用 NextJS 构建网站，使用 create-react-app 构建 SPA。后端使用 Node/Express，如果需要 CMS，则使用 MSSQL 和 Storyblok。
它们是每个项目的合适工具吗？当然不是，但我正在精通所有这些工具，而且我是按小时付费的，所以我没有时间为每个项目学习新的栈。
出于同样的原因，我知道很多人在每个项目中都使用 WordPress，即使它很少是最佳选择。
答案是什么？我们是否都需要学习所有工具，以便能够始终使用最合适的工具，或者工具和框架需要更加灵活，以便能够覆盖尽可能广泛的使用场景？
想象一下，如果网页开发者只需要学习一个栈，这个栈足够灵活，可以用于他们被要求参与的任何项目，从小型不变的静态网站到大型动态渐进式 Web 应用……
没那么快。以“每个人都对”为结尾是一个廉价的胜利。我在工作中处理的应用程序被重写了好几次，最初使用 jQuery，然后是完整的服务器端 cshtml，然后是使用 React 和 API 的完整的静态页面。乍一看，使用 React 的静态页面似乎最快 - 页面加载速度快（我们也使用了大量的 CDN 缓存），运行流畅，动画效果很好 - 都是很棒的。
但你猜怎么着？当我将应用程序加载到我的浏览器中时，我的笔记本电脑风扇开始疯狂地旋转。此外，代码最初非常干净，使用起来很愉快 - 但现在它变得和服务器端 cshtml 一样糟糕。我认为它比 jQuery 更糟糕，但那是很久以前的事了，我可能错了。当然，代码看起来/运行方式是这样的，因为代码不是由总是能够完美组织代码的大学教授编写的。代码是由多个团队编写的，有些团队在其他国家，有些是承包商等等。
这就是问题所在：在理想的情况下，React 速度很快，代码很干净，但在日常工作中，React 会使 CPU 占用率达到 100%，代码看起来很糟糕。这不是 React 本身的问题。这不是 React-router 的问题。这不是 React-async-actions 的问题，也不是 Redux、Webpack，也不是整个 node_modules 文件夹中的数百万个依赖项，我们每天都必须使用 snyk audit 检查它们。不，不，问题是所有这些工具都给开发环境带来了沉重的负担，一个简单的服务器端 HTML（或 cshtml）始终比所有这些栈运行得更快。
Webpack 构建需要几分钟？至少对于我们的应用程序来说是这样。而且它有时无法删除 node_modules 文件夹，因为它被另一个构建系统使用？你明白了吗？在 cshtml 时代，我们从未遇到过这些问题。或者在 jQuery 时代。或者在 2020 年的纯 JavaScript 时代。所以，是的，我对 React 有很多不满。它是个骗局。它应该很好，但它把整个开发环境变成了一个笑话。
抱歉，我发牢骚了……
与其仅仅考虑性能的理想情况，还应该考虑开发和维护的成本、适应市场变化和新需求的速度等等。
HTML（和 CSS）是可见的 UI。在我看来，在服务器端进行可见 UI 可能只有一个合理的理由，那就是 SEO。如果你可以在用户端实现你的用户界面，为什么不这样做呢？它天生更简单、更快、更容易构建和更改、带宽效率更高，而且是常识 - 试图解决远离用户/客户端的 UI 问题会增加一层复杂性，性能约束，并且通常会带来很多“混乱”，因为试图在客户端解决松散的连接（主要是交互式 UI）。
在我的经验中，静态前端和一些 API 始终比其他方法更简单，更易于维护。我个人不会使用任何类型的服务器端渲染，除非页面上有一些可以被索引的内容。除此之外，我并没有真正发现从服务器端生成 HTML 的令人信服的原因。
从我的角度来看，客户端 UI 框架和 API 使网页开发总体上比过去更简单、更高效、更令人愉快。我真不明白为什么有人会认为不是这样？
不错的总结。我同意他们两人都有很好的观点。定期反思和评估是健康的。我认为 Tom 文章的核心就是做到了这一点。我也喜欢 Rich 和他的团队在 Svelte 上所做的事情。然后，结合 Deno 的新闻，我觉得 JS 开始出现第三波的迹象（正如 Rich 在他的一个演讲中提到的那样）。
我认为这一切归结于开发者如何实现 React 提供的工具以及网页应用本身。简而言之，React Js（Vue 或 React 等）赋予你更多的能力。如何使用这种“能力”取决于你。
值得注意的是，在静态网站上，可以通过整合 instant.page 在悬停时预加载页面，无需任何手动操作。通过一些手动操作，你可以使用 Barba.js 将其转换为 SPA，而与 React 相比，使用的 JavaScript 代码更少。（我希望看到一个更简化的 Barba.js 版本，它只关注 SPA 方面，而不包含动画，但我还没有找到）。
我对 React 及其生态系统 - 包括构建/部署实践和广泛的 UI 设计模式 - 越来越反感。
这些框架会在网站上引入一些难以察觉的问题和故障，这些问题可能会令人十分恼火，但性能通常只是足够好，以至于没有人会关注它们。
这些框架和构建过程会生成冗余、模糊且对 Web 高级用户来说很不友好的页面结构。
而“响应式设计”已经变成了“移动端设计”。大多数网站在桌面上的外观都很糟糕。它不再有任何“响应式”的特性，仅仅变成了一个流行词。这是由于懒惰或“足够好”的思想造成的。开发人员依赖于工具和现成的组件来完成一项无法自动化的工作。设计一个真正响应式的网站并不简单，它需要在两种截然不同的纵横比下都能良好运行。
**Twitter.com*就是一个很好的例子**
超过一半的屏幕都是空的。“响应式”我的屁股。
浏览器的查找功能在这个页面上无法使用，因为当你滚动页面时，框架会从页面中删除元素。糟糕的 UX。
页面结构是一个地狱般的树形结构，包含数百个嵌套的 div 和毫无意义的 CSS 类。如果我想改变某些东西，我需要花一个小时的时间去分析究竟发生了什么。
我经常访问的另一个网站——deviantArt——最近推出了一个基于 React 的新改版。现在它的性能更差，用户体验也更差，并且缺少旧版本中的许多功能。
而这已经成为这个新的“现代 Web”的趋势，我对此深恶痛绝。
从我作为 Web 开发人员和 Web 高级用户的角度来看，**这些框架仅仅是另一种新的妥协方式**。一种生产力的假象。