本文翻译自 Things you forgot (or never knew) because of React，作者是 Josh Collinsworth，是 Deno 团队的高级前端工程师。译文在保留作者意图的同时，部分内容做了删改。

戳破 React 的泡沫

我之前写过关于 React 是新的默认前端框架的文章，以及我认为大多数经常使用 React 的人并没有意识到它已经落后了多少。

假设我们只是在谈论个人喜好，我永远不会写一篇博客文章来争论你喜欢什么，或者试图改变你的想法。（至少在这个时代是这样的。）谁在乎呢？如果你喜欢，就尽情享受吧。

但与音乐或其他为我们自己享受而存在的主观事物不同，我们对前端工具的选择对他人有着经验性、可衡量的影响。

那个决定带来了真正的责任。这不仅仅是关于我们喜欢什么。当涉及到开发时，除非我们纯粹为自己写的东西，否则我们的享受是次要的；用户的体验才是最重要的。

如果你喜欢你的工具，那太棒了！我希望你是这样的。但这只是一个次要任务，最坏的情况下可能会成为一种潜在的有害干扰。开发者体验（DX）永远不应该超越用户体验（UX）。当涉及到我们使用的开发工具时，我们有非常合理和重要的理由去离开我们现有偏好的舒适区。

React 泡沫

对于 React 落后于其竞争对手的观点可能让你耳目一新。像许多人一样，你可能仍然认为 React 是前端的现代标准。所以在我们进入话题之前，让我们快速戳破这个泡沫。 Alex Russell 通过 Mastodon 发表的内容，这是我写这篇文章的起因：

今天有人问我，如果一个新的应用程序不需要支持IE，是否有使用React的理由。

我想不出一个理由..

React的陈旧程度令人惊讶。

在那个帖子中，Alex 提到了 React 对 web components 的支持不足。这个功能在 React 中已经明显缺失了多年。是的，这个功能“在路线规划图上”。然而，就目前而言，对于实现或预期的发布日期都没有明确的承诺。

与此同时，几乎所有与React同期的框架或技术———无论你选择哪个代替 React 的——都已经在生产中实现了这个功能。

web components 只是其中一项。但它们远远不是“其他所有东西已经做得更好”的清单上的唯一项目。（我们将在下面介绍其他几个项目。）

React 得益于它在前端框架的战争中很早就占据了先机，它确立了标准。但这也带来了敏捷性和适应性方面的严重缺陷。自2013年左右诞生以来，React 所做出的每个决策都增加了技术债务的负担，而这是它的新一代竞争对手所不受限制的。

React是为了2008年的浏览器限制而设计的2013年技术。在2023年，它没有任何创新；事实上，它是在现代函数式-响应式前端编程最慢的方式...

所以，如果你是过去几年来一直沉浸在 React 世界中的众多开发者之一，可能有些东西你已经忘记了，或者根本就不知道，因为你已经使用React很长时间了。

随着现代前端的快速发展，我们似乎非常缓慢地意识到：那个将 React 加冕为王的世界已经不存在了。（如果它曾经存在的话；起初并没有多少团队面临类似 Facebook 那样特定的问题。）

在过去的十年中，浏览器在 JavaScript 和 CSS 的新功能采用方面取得了巨大的增长。技术和用户期望已经发展，当前的工具生态系统在超越React方面进行了更多的迭代和适应，这是传统软件所无法比拟的。

我意识到将React称为“过时软件”是有争议的，但我认为这是公平的；相对而言，它相对复杂，相对古老，包含许多规则和陷阱，初学者常常对它感到害怕，而且它构建在的架构决策早已成为其迭代能力的障碍。

如果到目前为止你还对我的描述感兴趣的话，我想分享一些你可能错过的东西。

因为React而忘记（或没了解过）的事情

你的生态系统不再需要庞大了（因为它现在可以共享）

我在其他帖子中已经提到过这个问题，但每当一个“未经验证”的框架的名字被提及作为开发项目的潜在工具时，似乎每个人都关心的第一个问题是：这个生态系统有多大？

你可能在读到这篇文章的开头就有了这样的想法。从React转向另一个框架？现在有哪个框架足够强大呢？

为什么我们对生态系统的规模如此着迷？

当然，我们希望确保这个框架不会突然消失，或者在几年后停止维护。这是完全合理的。是的，我们不会把所有赌注都压在太新或未经验证的东西上。但是 Vue、Svelte、Preact、Solid、Astro 等框架都已经远远超过了那个阶段，得到了良好的支持和维护。所以显然不仅仅是这个原因。

那么问题出在哪里呢？我有一个理论：

我们接受过训练，知道软件包必须专门为我们的框架构建。

你可以合理地认为这种心态始于 jQuery，但我认为 React 加速了它。

使用React时，每当我们需要一个特定的模块、小组件或库来执行某个特定的功能（如轮播图、地图、手风琴或其他任何东西），它必须是一个 React 的东西；普通的 Web 东西或纯 JavaScript 东西是不行的。React的所有规则、状态处理和组件生命周期的特殊性意味着，任何未明确为React编写的可用包或库可能都无法正常工作。

React潜移默化地让我们明白，事物需要专门为某个框架构建。但这种说法现在已经不太准确了，甚至可以说从一开始就不应该如此。

我们不应该需要这样做 - 尤其是对于一个经常声称自己只是“纯粹的 JavaScript”的框架来说。如果它只是 JavaScript，那么它应该能够与任何真正只是 JavaScript 的东西一起正常工作。

当然，其他前端框架也有它们自己关于状态和架构的规则和约定。你也可能在它们的领域里踩坑。是的，总会有一些东西是需要专门为 Svelte 或 Vue 或其他框架构建的，而且必须如此。

但是至关重要的是——我想尽可能强调这一点：

没有其他现代前端框架像React一样与平台坚决不兼容。

如果您正在使用其他现代工具和框架进行构建，那么很可能可用的原生 JavaScript 包会非常适合您，而且有成千上万个可供选择。它们很少会引起渲染周期或其他特定于框架的问题。更不用说：它们都可以选择使用 web components。

通常情况下，你不需要一个专门为你的事物量身定制的特定软件包或库，因为你的事物很可能已经与平台兼容，因此也适用于其他已经存在的一切。

Preact Signals 是一个绝佳的例子：虽然是为Preact设计的，但它可以被导入并在任何框架中使用，甚至在原生JavaScript中也可以使用。web components 也与几乎所有现代非 React 框架兼容。

当框架不足以满足需求时，很可能平台已经提供了你所需要的功能。（例如表单提交，在React中常常是一个痛点，现在通过双向数据绑定和利用浏览器提供的约定，变得无比简单。）

最糟糕的情况是，构建你所需的任何东西可能比在React中更容易。（只需比较一下其他框架实现的 useState，就能看出这一点。）

在保守思维的开发人员眼中，新东西往往被视为劣势，他们不愿意尝试那些没有经过全面审查的事物。但是，我们要记住，新东西也有优势，因为它们没有太多技术债务和旧浏览器的支持问题，可以更进一步地迭代现有的好想法和更现代的浏览器功能。

React hooks 实际上有点过时了

hooks 是 React 的最新演进，取代了类组件。

功劳应该归于 hooks：它们在前端领域带来了巨大的变革。它们彻底改变了我们在应用程序中组织逻辑和状态的方式。毫无疑问，hooks 非常出色，几乎每个框架都围绕着类似 hooks 的模型来管理状态。

但是React hooks现在已经不再是新鲜事物了。（事实上，带有 hooks 的稳定版 React 几乎和我的孩子一样大，他将在几周后开始上学前班。）

hooks 不再是竞争优势，甚至不再是显著特点；它们已经成为基本要求。它们只是我们做事情的方式。

每个其他框架不仅有自己的 hooks 实现，而且值得注意的是：每一个都更快、更智能、更容易编写，或者三者兼具。

在这里，值得一提的是 preact 的 Signals；Svelte 的简单易用的 stores 也是如此。Solid 也有 Signals。甚至 Vue3 的组合 API，直接受到 hooks 的启发，与 React 的实现相比具有一些关键优势。

hooks 是一种很棒的模式，React 应该因为推广它而受到赞赏。但实际上，几乎每个其他框架都以更少的规则和更少的样板代码更好地实现了 hooks。

如果你对“signals”这个概念不熟悉的话：这只是一个粗略的简化，但你可以将其视为响应式状态的下一个、更好的演进；它是对钩子的更新，具有更好的默认设置，可以确定重新渲染的原因，只重新渲染需要重新渲染的节点，而不是整个组件。

你不再需要过度管理渲染了

我有一个坦白要做：我仍然不太确定 useMemo 和 useCallback 之间的区别是什么，或者在什么情况下应该使用它们，尽管我今天早些时候确实阅读了多篇关于这个确切主题的文章。（不是开玩笑的。）

我有第二个坦白：我仍然不直观地知道应该把什么放入 useEffect 依赖数组中，或者为什么要这样做。我觉得每次我写一个 useEffect 调用时，我都要花大约15分钟重构我的代码，以使其符合代码检查工具的要求，即使我99%确定它实际上是没问题的，不会让我的应用程序陷入无限深渊。

如果你使用React，你可能会对这些场景有所共鸣。或许你甚至已经接受了混乱和模糊作为正常现象。但是如果是这样的话，你应该知道：

多年来，我们在其他框架中没有遇到过这种渲染周期的微观管理。

现在的框架已经足够智能，可以处理这种事情，而无需你手把手地解释它们应该做什么。

他们已经知道不要在没有真正需要的情况下浪费宝贵的资源重新渲染。他们足够聪明，只更新值，而不是不断重新评估不需要的事物。

大部分时间都是这样。它们并不完美，但比起 React 来说，它们在知道该做什么以及以高效的方式去做方面要好得多。

你可能也需要优化其他框架中的一些东西。它们并不完美。但是当你这样做的时候，你已经远远超过了在 React 中需要优化的点。

没有人害怕他们框架的 useEffect

当你希望一个组件在进入DOM时只执行某些操作，或者当你希望它根据其他数据或变量动态地重新计算某些内容时，几乎每个其他框架都有比 useEffect 更好的方法。

我不认为我需要在这里过多强调，因为即使在React社区内部， useEffect 也被认为是臭名昭著的危险功能，通常甚至被完全避免使用。但请相信我：没有其他非React前端框架会让人们如此害怕使用如此正常、有用的功能，也没有其他地方对此有如此晦涩的规则。

没有其他人会只是为了在组件挂载时做一些事情而去寻求第三方包，简直是搬起石头砸自己的脚。

扩展性不再是前端关注的重点

当一个比React更新的框架出现时，人们立刻会问的另一个问题是：它能扩展吗？但我相信这个问题可能有点过时了。

值得记住：给我们带来React的世界有一套不同的问题。

在那个世界中，大多数前端用户界面要么使用原生 JavaScript 构建，要么使用 jQuery（或类似的替代方案）。而我们现在知道，这种构建应用程序的方法在一定程度上无法良好扩展。

这是因为你必须为每个元素和DOM节点编写自己的选择器，并且你必须想出自己的手动方式来跟踪和同步状态。这通常涉及到对DOM的写入和检索，这是混乱、容易出错，最重要的是，速度很慢。（这就是虚拟DOM的作用，但即使是虚拟DOM在多年来也已经相当过时了。）

过去编写模块化代码很困难，甚至几乎不可能，JS文件经常膨胀到成百上千行。如果多个作者在同一个项目上工作，他们经常会重新发明、重复或甚至覆盖彼此的代码（部分原因是因为代码经常进入共享的全局命名空间，这使得冲突更加可能）。而且你的应用程序越大或越复杂（比如Facebook），问题就越严重。

重要的是要记住：这是我们对前端“是否可扩展”的基准。即使我的应用程序呈指数增长，它是否仍然保持合理可维护性？

担心前端框架无法扩展的担忧从 jQuery 时代就存在了，与现代网页开发相比，这种担忧应该被视为过时的。

React 解决了许多这些问题，是的。但它并不是通过成为现代工程的奇迹来解决这些问题，而是通过找到一种良好的方式来管理和共享状态，使数据具有响应性，抽象复杂性，并使开发人员能够共享相同的编程模式，而不会发生冲突、命名空间冲突或覆盖。

React并不是前端可扩展性的最佳、唯一或者第一个解决方案；它只是同一范式的众多可能版本之一。

（它也恰好是最古老的之一。）

我怎么知道这个？因为已经进行了大量的基准测试，并且有公开可查的结果，比较了React在大规模情况下与其他前端框架的性能。它们都证实，前端领域的几乎每个其他选项都比React表现得更好，而且在许多情况下，要好得多。

在这里，我指的是一般意义上的扩展；确保复杂性保持最小，并且不会随着应用程序规模的增加而线性增长。当然，某些框架在从Markdown文件构建静态HTML或其他更专业的任务方面，扩展能力会比其他框架好或差很多。

服务端渲染不再特殊

几年前的某个时候，React 几乎是唯一一种在服务端渲染内容的选择（主要通过 NextJS）。人们对 React 可以作为 HTML 在服务端渲染而不是在客户端作为单页应用程序（SPA）的想法感到非常兴奋。无法忽视的速度和 SEO 优势，最初其他框架需要一些时间才能迎头赶上。

然而，正如一般情况下的这些事情，以及特别是这篇文章：第一次迭代往往不是最好的。

SvelteKit 默认情况下是服务器渲染的，无需您做任何操作，并且提供对其渲染模式的精细控制。Nuxt是 Vue 的元框架，很早就出现了（显然受到了 Next 的启发）。

Fresh（Deno的前端框架）完全是服务器渲染的，除了你指定为“岛屿”（客户端渲染）的部分，其他所有内容都以静态 HTML 形式传送。Fresh 还使用 Preact（比 React 更快，具有Signals，一种更高性能和人性化的版本的 useState 和反应性模型）。

Astro具有服务端渲染功能，并且可以让您服务器渲染任何类型的组件。它可以很好地渲染其他框架的组件，并且在某些情况下甚至被认为是Next的重大性能升级。

SolidStart（Solid的元框架）具有服务器渲染功能。Qwik完全基于此构建。甚至一些较旧的框架，如 Ember 和 Angular，也添加了这方面的功能；我肯定还遗漏了其他的框架。

重点是：很久以前，React是少数几个在服务器上渲染客户端视图框架组件的概念之一。但现在，服务器渲染已经成为基本要求。许多较新的框架不仅具有在服务器上渲染的选项，而且默认就是这样做的。

PHP回来了！

双向数据绑定并不难，也不是一个坏主意

我认为重要的是要记住，React是由Facebook创建的，旨在解决Facebook独特的一系列问题。

React的一个最强烈的想法是数据应该只能单向流动（自上而下），这是Facebook在2010年代初期的工程挑战如何不可磨灭地塑造了React的架构的一个很好的例子。

有一段时间，似乎单向数据流被认为是最佳实践。然而，如今我们大多数人已经找到了解决双向数据绑定问题的方法，并发现在许多情况下，它实际上更加方便。

在 React 中处理表单是非常麻烦的，因为每次用户输入都需要进行两个步骤：获取输入的值，然后设置状态以匹配它（这又不必要地重新渲染输入框，以包含与React状态已经同步的确切值）。当然，这通常太快以至于察觉不到，但这是很多额外的工作。

Svelte、Vue 等其他框架没有这个问题。你可以简单地绑定状态，使其自动从两端更新。如果状态改变，DOM会更新；如果DOM改变，状态也会更新。

这样，你就不必进行多步骤的操作了。如果你只想捕获文本框的值，你可以使用双向数据绑定。然后，当用户在字段中输入时，数据会自动更新，你可以在合适的时候获取它，无需进一步操作。如果同时你需要执行一些操作，比如设置一个值或清空字段，那也只需要一行简单的代码。

双向数据绑定可以让你在不需要不断确保数据和DOM保持同步的情况下，保持它们之间的一致性。

使用这些东西可能会惹上麻烦。但我发现，教条主义的最佳实践理念往往阻碍了进展。单向数据流就是一个典型的例子。

CSS 样式实际上很容易

如果你主要使用React，很可能你已经经历了两次、三次甚至更多次在前端组件中处理样式的迭代。

你可能已经将 .css 文件直接导入到 JSX 组件中，或者使用了CSS modules 、styled-components 或Tailwind（可能使用了 classnames 或 tailwind-merge 包，甚至可能同时使用了两者，再加上一些额外的Tailwind 插件）。而这些只是最受欢迎的选项之一。

Tailwind是一个自成一派的东西（也是一个我不太喜欢的前端框架；我认为它违背了浏览器的原则，只为了短期的收益，最终导致了长期的损失）。但无论如何，这些样式解决方案存在并且得到了广泛采用，至少部分原因是因为React在它存在的整个时间里都没有提供官方的样式选项。

你可能没有意识到，在其他几个框架中，样式问题已经得到了解决。

特别是，Vue 和 Svelte 都有自己的组件样式方案。它们都具有组件级别的作用域（Vue 是可选的；Svelte 是默认的）。如果你愿意，它们都可以很好地与原生 CSS 一起使用。但是它们以及其他所有前端框架都与 CSS modules、Tailwind、Sass或其他你喜欢使用的工具兼容。

但最重要的是：所有关于CSS的所谓问题，无论你是否认为它们是问题，都已经完全通过内置的样式处理解决了。你不需要在其他地方使用一堆包和配置，因为带作用域的 CSS 几乎解决了你可能想象到的每一个问题。

认真地阅读任何一份关于CSS为什么被认为不好的理由的清单（实际上并不是这样，只是那些不擅长CSS的人喜欢这么说）。几乎你可能对CSS提出的任何批评都可以通过作用域样式解决，并且多个非React框架已经内置了这个功能。

现在学习框架不再那么困难了

我推测接受过 React 培训的开发者会回想起学习它的困难，并以类似的方式评估其他框架的学习曲线。这可能是我们不愿尝试新事物的一部分原因；因为第一次学习 React 确实很难，所以新的东西看起来也很难。

所有关于状态管理、props、嵌套、组件生命周期、hooks，当然还有如何编写 JSX 的细节...这真的很多。即使是最热衷于 React 的粉丝们也可能会承认，对于初学者来说，这并不是一件容易快速掌握的事情。（任何说相反的人可能已经忘记了自己当初是如何入门的。）

如果你能理解，我有个好消息：

没有任何一个工具像 React 一样难学。一旦你掌握了一个框架，你就在其他所有框架上占据了巨大的先机。

我把这个比作学习第二个乐器。第一次学习演奏乐器时，你需要学习音乐的方方面面，同时还要学习特定的乐器以及如何使其发出你想要的声音。但是当你学习第二个乐器时，你可以省去很多步骤。所有的概念都是熟悉的。你理解音乐。你所需要做的就是将你已有的知识和肌肉记忆转化为稍微不同的形式。

前端很相似：每个前端框架都有组件；它们都与 TypeScript 兼容；它们都有 props、children 和响应式状态的概念。这些是我们普遍认为喜欢和好的东西。只是在实现上有不同的方式。

说到这一点：虽然 React 无疑有助于推广这些想法，但认为 React 是它们的理想实现是愚蠢的。

伟大的事物是通过迭代创造的，而在前端领域中，后来出现的其他选择大多都有在 React 的核心思想基础上进行迭代的明显优势。

这意味着 React 有点像一个落后主分支很多的 git 分支。如果 React 是你的整个前端世界的核心，你可能没有意识到，但是前端已经进步了。整个生态系统已经借鉴了这些想法，并且通过创造出更好的东西来推动前进。

现在我们有很多更高效、更简单、更易学的选择。如果你已经了解React，学习它们也不会很困难。

其他选择不仅仅是“新而闪亮”

当我讨论这篇的文章时，经常听到的一句话是：

那些愚蠢的JavaScript开发者，总是追逐那些看起来高级的新玩意儿！他们不在乎长期维护自己的项目。明天这个炙手可热的新框架就会被遗忘，他们的代码甚至无法运行！

这里有一点真实的迹象。没错，JavaScript 开发者（我敢说前端开发者普遍如此）似乎对新事物有一种吸引力，而其他编程专家则更加谨慎。

但这到底有多真实呢？我们确定全世界的 JS 开发者都会在有新技术出现的时候急于重写他们的整个技术栈吗？还是这只是一种被无尽的网上的炒作所影响的感觉？

我认为任何一项技术的早期采用者往往是受到关注的人；他们是撰写所有博客文章和制作所有视频的人，这些内容又会被分享和讨论，从而使得这种行为似乎比实际情况更为普遍。（毕竟，如果上面这种说法有一半是真的，React 的市场份额将远远低于目前的水平。）

我遇到的大多数前端开发人员都坚持自己所熟悉的技术，就像其他类型的开发人员一样。我认为对于我们来说，尝试新事物的成本稍微低一些，所以我们会去尝试。

然而，这都不是重点：这种观点低估了该领域中其他可用选项的成熟程度。

Vue已经存在了和React一样长的时间，它的当前版本（v3）发布了将近三年。现代版本的 Svelte 是在 React hooks 发布两个月后推出的（你以为 React hooks 是两个月前才新鲜出炉的吗？），而 SvelteKit 在将近一年前达到了1.0版本。Preact 已经更新到了第10版，Solid 已经超过两年的时间保持在1.0+ 版本。Astro 在一年前达到了1.0版本。Qwik 和 Fresh 是我在这里要提到的最新项目，但它们在今年早些时候都已经达到了1.0版本。

所以如果其中一些条目对你来说还是有点新，那没关系。我理解。但是过于忽略 React 替代方案是对领域中可用的成熟度和深度的一种错误概述。

React在性能方面远远落后

我不会在这里过多地强调这一点，因为关于这个话题已经有很多文章了。但可以说的是：在React速度较慢的地方，可能看起来只是微不足道的差距（尤其是如果你有足够特权使用非常新的/高级的硬件，并且拥有非常快的互联网连接）。但这种差异绝非微不足道。

React在性能方面落后于许多情况下的2倍或更多（这里指的是包大小和执行速度，包本身可以是10倍或更多。）最新的JS web frameworks benchmark 测试显示，React的性能平均比 Solid 慢近50％，比 Vue 慢25％，比 Svelte 慢40％，比 Preact 慢35％。（在此特定测试中，其他框架不可用。）

还有其他研究。我相信各地的数据可能会有些不同，而且我相信他们的研究结果总是有细微差别的。但是：

无论你参考什么结果，React 几乎都会比之前的任何东西都更庞大和更慢。

据我个人经验：作为一个用户，当我在 Android 上填写表单时，我可以感觉到是否使用了 React。它会有一种缓慢的感觉，以及不断更新 DOM 以匹配状态，再匹配 DOM 的循环，这种感觉只有在使用 React 时才会注意到。

但是忘记我的个人体验吧；我们只看到了数据。我知道这些数字可能听起来不大，而且性能只是选择技术栈时的众多考虑因素之一。“这完全取决于情况。”

但是我们要认识到，性能提升25%至50%是非常巨大的。让前端加载速度快上两倍对用户来说远远超出了微不足道的范畴；我们谈论的是在规模上造成巨大差异的数字。

我相信我不需要引用大量的研究来证明每一秒的宝贵性，当加载网页或等待操作完成时。我也希望我不需要告诉你要考虑那些可能没有足够带宽下载庞大 JavaScript 包或者没有足够计算能力等待框架对页面所做的每一次更改的用户的重要性。

任何一位工程师如果能够消除一大块的 loading 和代码处理时间，那将成为他们简历上的一大亮点。这可是一件大事。

React与其他领域的性能差异并不是微小的，而是被最小化了。

你应该尝试的

你可能在几十段前就开始疑惑了：如果 React 如此过时，那么有什么替代方案呢？

我将在这里涵盖几个，并提及它们的使用情况。React 的一个问题是，它一直试图成为适用于所有人的一切，虽然一个形状像 React 的工具可能很有用，但我认为也许两到三个不同的工具比一个瑞士军刀更好。

svelte

2023年了：请使用Svelte吧！

如果我只能给你一个未来的建议，那就是选择Svelte。

开玩笑的话：如果我从这个列表中选择一样东西来推荐，而不是 React，那就是 Svelte。我一直坚持认为“Svelte 就是没有废话的 React”，正如我在2019年在 Twitter 上开玩笑时所说的那样，而且随着时间的推移，这一点只变得更加真实。

Svelte 使用起来非常简单，相对容易学习（尤其是如果你已经熟悉 React 的话；甚至语法也常常相似），在几乎所有情况下都更加高效，并且能够做到 React 能做的一切，甚至更多。这个网站以及我所有的个人项目都是用 SvelteKit 编写的。

Svelte很快，可以与最快的框架相媲美。它的开发体验非常出色，经常在开发者调查中名列前茅的位置。

Svelte尽可能地与Web平台保持一致，因此即使它非常强大，它的概念也会非常熟悉。Svelte还包括过渡动画效果、缓动函数、CSS 处理、组件范围的样式以及更多便利功能。

这可能会让你对框架的大小产生疑问，但 Svelte 的区别在于：它不是一个 JavaScript 运行时，而是一个编译器。在构建时，任何你不使用的东西都会被剥离，你的代码会被转译成一小段纯净的 JavaScript 代码。这意味着Svelte 的捆绑包通常只有 React 的一小部分大小。

虽然它感觉和使用起来像一个框架，但实质上，Svelte 是一个小巧而优雅的 HTML 超集，具有简洁明了的语法，可以编译成快速且精简的捆绑包。

Svelte的元框架 SvelteKit 非常灵活和强大，能够进行静态渲染、服务器渲染、边缘部署，甚至 mixing per-route。它在2022年底发布了1.0版本，并且非常适合生产环境使用。（它也得到了 Vercel 的支持，Vercel 也是Next.js的开发者。）

如果符合以下条件，建议使用 svelte：

你想要重新发现前端的乐趣，出于以上原因，我认为这是最全面的选择。

svelte 可以替代：

无论你在使用 React 做什么，Svelte 都可以取代 React 本身，或者 SvelteKit 足够灵活，可以替代 Next、Gatsby 或 Remix。

vue

Vue可能是最接近React的选择，也可能拥有第二大的生态系统。然而，它比React更高效，并且更加注重用户界面。

在某些方面，Vue 是从 React 迈出的最小一步，尤其是现在 Vue 3 采用了类似 hooks 的方法。但是，Vue 使用的模板语言更接近默认的 HTML，而不是 JSX，这使得在模板文件中编写条件和循环要容易得多，而无需使用像 map 和三元运算符这样的变通方法。

Vue在Nuxt中有一个类似于Next的元框架，它得到了很好的维护，并且不断添加强大的新功能。Vue比React更加全面，内置了诸如作用域CSS处理和简单的过渡/动画等功能。

如果你符合以下条件，我们推荐使用 vue：

社区规模/整体框架的受欢迎程度对您来说是一个重要因素；您希望找到类似于 React 的东西，但更加全面或类似于HTML；您更喜欢独立的框架，而不是由大公司拥有。

vue 可以替代：

React 本身，或者 Nuxt 可以替代你可能正在使用 Next 的任何东西。

solid

我认为 solid 才该叫 react，但他更好。在许多情况下，它看起来几乎（如果不是完全）与 React 相同，但 Solid 的性能要好得多。实际上，它是目前可用的最快选项之一。

solid 基本上是以 React 为基础，然后重新思考并消除了复杂性、性能问题和大量的样板代码。在 solid中，signals 出现作为一个概念，它消除了组件渲染和生命周期的许多混乱和问题。甚至可以说，如果 React 是在现代时代构建的，并结合了我们自2013年以来所学到的所有经验教训，那么 Solid 就是 React。

solid 还提供了自己的元框架 SolidStart，尽管目前还处于测试阶段。不过，solid 本身已经足够成熟，拥有令人印象深刻的赞助商名单。

如果符合以下条件，建议使用 solid：

你通常喜欢React（和JSX），但你希望它更现代化、更快速、更容易使用；性能是绝对的首要任务。

solid 可以替代：

React 和 ReactDOM。SolidStart 有望在未来取代 Next，但截至目前，它仍处于测试阶段。

Fresh

Fresh是一个基于Deno构建的服务器渲染前端框架，采用岛屿架构。它比列表中的大多数项目都要年轻一些，但作为一个最小化 JS、基于岛屿的框架，它充满了潜力，可以在边缘运行——更不用说它是由 Deno 提供支持，这意味着您的服务器代码更快、更安全，默认使用 TypeScript，并且具备 Deno 相对传统 Node 的其他优势（例如更简单的官方代码检查、测试和代码格式设置）。

每个 Fresh 组件要么在响应时间作为 HTML 进行静态渲染和提供，没有 JavaScript，要么是一个“岛屿”，这意味着它只在客户端渲染。您可以根据需要混合和匹配。由于它在 Deno 上运行，这为在世界上任何地方的任何设备上尽快加载的极快、动态内容打开了大门。

Fresh 使用 Preact，所以你知道它很快，如果你之前使用过React，上手也不会太难。再次强调：在 Deno 上构建感觉很棒。

如果符合以下条件，建议使用 Fresh：

你喜欢在云端全球范围内提供的服务器端应用的想法，只需使用极少量的JavaScript，或者基于最新的技术进行开发。

Fresh 可以替代：

Remix 可能是 React 领域中最接近 Fresh 的东西。

Astro

Astro是一款高性能的下一代静态网站生成器，不仅仅是静态。Astro 是这个列表上最新的选择之一，但它已经稳定到了1.0版本，并且得到了广泛的赞誉和采用。

Astro主要是为了成为新一代的SSG（嘿，React 的粉丝们：它支持 JSX 和 MDX），现在还具备了动态的、服务器端的能力。对于任何内容丰富或静态网站，我绝对推荐它。

真正的杀手级功能是：Astro 默认情况下不使用任何 JavaScript。您可以选择仅使用您想要的部分。

Astro也与您想使用的任何前端框架兼容，所以如果您更喜欢在 React、Vue、Svelte 或其他框架中进行模板编写，都可以！

如果符合以下条件，建议使用 Astro：

你正在构建一个主要是静态的、或者基于内容 / Markdown 的网站（即使你可能需要一些服务器端渲染或逻辑）；你希望尽量减少 JavaScript 的使用；你想使用自己的前端框架。

Astro 可以替代：

Remix 可能是 React 领域中最接近 Fresh 的东西。

Preact

如果你生活在React的世界里，你可能已经对 Preact 有所了解，但它在这里值得一提。它是 React 的一个更加精简、更加快速的版本。虽然它最初是作为 React 的替代品出现的，但它开始拥有一些 React 没有的更优秀的功能（比如我们已经提到的 Signals）。

如果符合以下条件，建议使用 Preact：

你想继续使用React，但希望它更快一些。

Preact 可以替代：

React（实际上，它只是在开头加了个P。这个P代表性能（performance）。我猜的 :-)）

Qwik

Qwik使用一种新的水合和高性能的方法来渲染类似于React的代码（JSX）。实际上，它所做的事情根本不能被称为“水合”；相反，它将 JavaScript 序列化到 DOM 中，并且仅在需要时以微小的块加载。Qwik 是这个列表中更深入的部分之一，但如果您有很多需要尽可能快速运行的交互性内容，它绝对值得一看。

如果符合以下条件，建议使用 Qwik：

你正在向浏览器发送大量的JavaScript代码，并且希望找到一种提高性能的方法。

Qwik 可以替代：

React本身使其能够在边缘设备上高效运行。

结语

这篇文章，诚然，很像我去年的一篇文章The self-fulfilling prophecy of React。它涉及了一些相同的领域，并提出了一些相同的论点（尽管希望以新的方式或从新的角度来表达）。

我并没有打算重复自己，但显然，我对这些事情考虑得很多——毫无疑问，这是因为我在那篇文章发布的时候刚好转向全职使用React进行工作。

我开始相信React之所以如此受欢迎，很大程度上是因为人们没有去寻找其他选择。它并不是最好的，但大多数人并不追求最好；他们只是追求足够好的。（我们是人类。我们做决定有很多个人、情感和非理性的原因，这都没关系。我们很忙。）

在前端领域，我们似乎是以跳跃的方式采用技术，而不是线性的方式。大家纷纷加入React的行列，部分原因是当时大家都被陈旧的技术束缚住了，渴望找到更好的替代方案。我们并没有逐步迈向新事物，以小步骤前进（也许一开始就没有这个选择）；我们是从现有的地方一跃而至下一个事物。

但问题是：自从我们多年前迈出那一步以来，我们一直坐在那里，大部分时间都是在同一个地方。

我的感觉是：我们正在接近另一个飞跃。

我不知道它会是什么，也不知道为什么。但我觉得我们开始感受到 React 实际上并没有解决我们所有问题，就像我们在那些日子里感受到 jQuery 一样。我认为最终，我们会清楚地意识到是时候前进了。

那个新东西会是什么呢？我不知道。也许它只是 web 平台。也许我们甚至不需要框架。也许它会是一个更高级的框架；也许它会是我们从未见过的东西。也许它甚至不会是一个具体的东西；也许会有更多多样化的工具和少一些围绕一个单一标准的凝聚（尽管在上述所有选项中，我会说这似乎是最不可能的，因为人类嘛。我们是忙碌的小猴子，所以我们喜欢默认设置）。

我认为，React和那个东西之间的差距会随着时间的推移越来越大。

所以，每一天都比前一天更好，可以探索你错过的东西。

感谢阅读。