2024 年 React 10大趋势

讨论了 2024 年值得关注的 React 趋势，包括 Astro、认证、tRPC、React Server Components、TanStack Router 等。此外，还涉及 Vercel 推动 React 边缘部署、Turbopack 与 Vite 的打包工具对比、React 编译器、Biome 工具链和无头 UI 库等新兴趋势。总体来说，本文展望了 React 生态系统的发展方向和未来可能的变革。今日前端早读课文章由 @飘飘翻译分享。

正文从这开始～～

2024 年再次让我对 React 的生态系统感到兴奋。尽管去年我们遇到了各种挑战和麻烦（其中最大的麻烦是通过 React Server Components 将 React 移到服务器上），但仍有一些新兴的 React 趋势值得每个人关注。以下是我列出的 2024 年令人兴奋的 React 趋势。

Astro（使用 React）

去年，Astro 成为了 Gatsby 的继任者。虽然它主要以静态网站而闻名，但其日益增长的受欢迎程度也推动 Astro 探索网络应用程序和 API 端点。因此，虽然它完全可以用于高性能网站，但网络开发人员开始考虑将它用于其最初想法之外的用例。

使用 Astro 构建的网站默认情况下性能很高，因为它们从零 JavaScript 开始，并将所有昂贵的渲染工作转移到服务器上。虽然静态网站生成（SSG）是默认设置，但您也可以选择服务器端呈现（SSR）。

Astro 并不与 React 严格绑定。您可以在没有任何 UI 框架的情况下使用 Astro，使用其在 “.astro” 文件中创建 UI 组件的原生方式。不过，Astro 可以让您选择使用自己喜欢的组件框架（如 React），您已经拥有了创建设计精良、功能完善的 UI 组件的所有经验。

当 Astro 与 React 等组件框架一起使用时，它仍然不包含 JavaScript，只向浏览器发送 HTML 和 CSS。只有在组件具有交互性的情况下，服务器才会向客户端提供必要的 JavaScript。所有这些都与 Astro 的 “默认快速性能” 息息相关，而这正是由其名为 “岛屿架构”（Island Architecture）的渲染范式驱动的。

我个人希望在 2024 年的项目中更多地使用 Astro。去年，它已经帮助我为一家新的初创公司构建了网站，该网站拥有完美的性能 / 搜索引擎评分、精美的主题以及由 Astro Starlight 提供的嵌入式文档。我想这只是时间问题，所有网站都会将其作为默认设置。在一个新项目中，我想尝试使用它的网络应用功能，包括身份验证、API 端点和服务器渲染内容。

身份验证（在 React 中）

React 中的 Auth 也再次变得令人兴奋，因为多家初创公司和开源项目开始在这一领域掀起热潮。虽然 Firebase Authentication、Auth0、Passport.js 和 NextAuth 在很长一段时间内都是默认设置，但我们终于可以探索价格低廉、用户界面驱动的身份验证替代方案的新领域了。

Supabase 是谷歌 Firebase 的开源替代品。它不仅提供认证，还提供 PostgreSQL 数据库、实时订阅、存储、无服务器功能等。Supabase 实例既可以自托管，也可以作为托管（付费）服务使用。不过，许多开发人员使用它来进行身份验证，而在其他方面则选择其他服务（如作为无服务器数据库的 PlanetScale）。

Clerk 是该领域另一个只专注于身份验证的竞争者。利用它为 React 提供的嵌入式组件，您可以轻松注册用户，然后将用户登录到您的应用程序中。除此之外，它还可以管理用户及其在一个或多个组织中的角色。我个人认为 Clerk 是初创公司启动新 MVP 的完美解决方案。

最后但并非最不重要的是 Lucia，它与 Astro 结合使用后大受欢迎，但也可用于其他框架。它的开源性、社区的努力以及在应用程序和数据库之间提供的清晰抽象层尤其令我兴奋。后者使得在自己的数据库中管理用户成为可能，与其他身份验证服务相比，这是一个巨大的优势。

用于全栈 React 应用程序的 trpc

去年，tRPC 已成为我最喜欢的类型安全全栈应用程序。在我的上一个单独项目（80K LoC）中，我使用 tRPC（和 Prisma 作为数据库 ORM）在数据库、服务器应用程序和客户端应用程序中使用 TypeScript 类型获得了类型安全。

简而言之，它是如何工作的？Prisma 从数据库模型中为后端应用程序生成类型，而 tRPC 则从后端为前端 API 层维护类型安全。也就是说，API 的类型不能与成长中的全栈应用程序中数据库模型的类型相同。

有了所有这些设置和 tRPC 的远程过程调用底层特性，客户端应用程序就可以通过调用普通函数来调用后端的 API。在引擎下，tRPC 使用 JSON-RPC 作为规范，HTTP 作为传输层。更妙的是：tRPC 可以与 react-query 结合使用，以便高效地缓存和批处理请求，此外还可以使用查询库带来的所有其他升级。

我很期待今年 tRPC 的发展方向，以及随着时间的推移，他们与 React Server Component 的正式集成将如何发展。说到 React 服务器组件…

React 服务器组件和 Next.js

React 服务器组件（RSC）是 React 发布的规范（包括底层实现），并在去年的 Next 13.4 中得到了实现和社区的首次采用。抛开所有的戏剧性事件和挑战不谈，React 服务器组件将网络开发推向了一个巨大的范式转变。

RSC 的转变可能比 React Hooks 更大，因为它们让我们重新思考如何在更大的应用中使用 React 组件。在 Next.js 及其新的 App Router 中，RSC 成为了每个 React 开发人员的默认设置。虽然有更多框架（甚至是 React 以外的框架）正在研究服务器组件的采用（和实现），但也有一些新兴的小型框架（如 Waku）已经实现了服务器组件。

这种新架构有很多好处，虽然很难在此一一列举，但我想举一个例子：RSC 使我们能够在将组件发送（或流式传输）到浏览器之前，在服务器上执行组件级的数据获取。这样做的好处是：从客户端到服务器之间可怕的瀑布式网络请求已成为过去。现在，瀑布式请求在服务器上发生的速度要快得多（如果有的话），这将提高我们的性能。

tRPC 和 react-query 用于客户端与服务器之间的通信，因此问题是，在一个没有 API 的世界中，RSC 将在服务器上完成大部分（？）数据获取工作，那么它们将扮演什么角色。现在已经有了概念验证，所以我们可以对 2024 年的结果感到兴奋。

用于 SPA React 的 tanstack 路由器

单页面应用程序（SPA）尚未消亡。这就是 Tanner Linsley 在 React Server Components 的炒作中对自己的定位。这有什么关系呢？他是最流行的 React 库（如 react-query 和 react-table）背后的推动者之一。最近，他又发布了一个新库：TanStack Router。

TanStack Router 的出现恰逢其时，填补了 React 生态系统中的一个重要空白。虽然许多开发人员都采用了 Next.js 和 Remix（Remix 在引擎盖下使用了最流行的 React Router，并且也专注于 RSC 的实现）等元框架的内置路由器，但还没有人首先为 React 创建一个类型安全的路由器。

在过去几年中，TypeScript 已成为行业标准，因此我很期待 React 生态系统中能有一个支持一流 TypeScript 的新路由器。例如，它将允许开发人员以类型安全的方式读写 URL 状态。也许这个新的路由器还能推动其他成熟的路由器提高到这些 TS 第一标准。

Vercel 推动React

Vercel 是 Next.js 背后的公司，而 Next.js 在整个 React 服务器组件运动中发挥了巨大作用。由于多名核心开发人员受雇于 Vercel，许多开发人员认为 Vercel 也是 React 的幕后推手。不过，撇开这些阴谋不谈，有人接过缰绳来推动 React 的发展是件好事。

Vercel 不仅通过 React Server Components 推动了 React 的发展，还通过 Next.js 推动了 React 应用程序的高效部署和交付。在 Vercel 上部署 Next 应用程序，还可以利用其 Edge Runtime 选择流式 React 组件。

从边缘为应用程序提供服务对性能的影响是巨大的，因为应用程序不再托管在用户偏远的地方（如美国东部），而是作为无服务器功能尽可能靠近应用程序的用户。无服务器数据库（如 PlanetScale）在世界各地都有读取副本，与之搭配，这将成为我们未来如何（或更好地）托管应用程序的一个有趣趋势。

用于 React 的捆绑程序：Turbopack 与 Vite

Turbopack（由 Webpack 的创建者 Vercel 构建）是 Webpack 的后继者。它尚未投入生产，但可用于 Next.js 应用程序的本地开发。Turbopack 从最流行的 JavaScript 捆绑程序（Webpack）中汲取了所有经验，并将其应用到新的 Rust 支持的捆绑程序中。例如，树抖动和缓存在 Webpack 中是事后才想到的，而在 Turbopack 中却得到了一流的支持。

过去，捆绑程序已经承担了很多责任。然而，随着开发和生产环境中客户端和服务器组件（如 RCS）的交织、应用程序各入口点的缓存以及了解组件级数据获取的需求等新兴趋势的出现，捆绑程序必须更上一层楼。因此，Vercel 开始需要一种新的捆绑程序。

就我个人而言，我希望 Nextjs 能使用 Vite 及其服务器端功能。不过，去年许多其他元框架（也包括 Remix）和单页面应用程序都将 Vite 作为捆绑程序，而 Vercel/Next 则决定暂时不使用 Vite，并开始着手开发 Turbopack。

React 编译器（称为 React forget）

作为 React 开发人员，谁不对 useCallback、useMemo 和 memo 感到沮丧。React 已经坚持了相当长一段时间的显式设计，而其他框架则不需要这些实用工具来提高性能。默认情况下，它们都是快速的。

【第3202期】React 将被编译

但是，React 团队正在（相对安静地）开发一款名为 React Compiler 的编译器，它将自动执行 React 应用程序中的所有 memo 化。备忘录化函数（useCallback）、值（useMemo）和组件（memo）的手动过程有望在未来消失。React 将为我们处理所有这些备忘录化工作，这样在下一次呈现时就不需要再次计算所有内容了。

最近，关于 React 19 及其新编译器可能发布的消息和传言不绝于耳。这一版本很有可能与 React Conf 2024 同时发布。

BIOME

说到 ESLint 和 Prettier，它们并不是最受欢迎的工具，尤其是在设置和交互方面（如果设置不正确）。但它们却是每个网络开发人员日常工作中必不可少的工具。Biome（前身为 Rome）希望通过提供快速的一体化工具链解决方案，成为这一领域的另一种选择。oxc 就是一个很有前途的一体化工具链。

Biome 向 Prettier 申请了 20000 美元的赏金，以在 Rust 中创建一个性能更强的格式化器。现在，只有时间才能证明开发者是否会采用它。很多地方都在讨论（例如 Next.js GitHub 讨论）如何摆脱对 ESLint 的严格依赖，并允许开发者使用其他衬砌器。

就我个人而言，我对这个项目感到非常兴奋，因为它可能会成为一个工具链，以一种非常快速的方式为现代网络应用程序提供所有必需品。

用于 React 的无头 UI 库

React 开发人员喜欢每年更换他们最喜欢的 UI 库。几年前，Material UI 过渡到 Semantic UI/Ant Design，然后是 Chakra UI，接着是 Mantine UI，去年又选定了 shadcn/UI。虽然之前所有的选择都主要是出于对设计和可用性的追求，但 shadcn/UI 已经改变了一些东西。

shadcn/UI 是第一个完全采用 Tailwind 作为一等公民（仅次于 CSS 变量）的流行用户界面库，可将其组件主题化以实现自定义设计。跟随 Tailwind 的脚步，shadcn/UI 并不是作为一个节点包安装的，而是复制粘贴到一个项目中，在那里可以自由调整组件。

无头用户界面库（Headless UI libraries）只提供骨架组件（功能、可访问性……）而不提供设计，这一趋势并非由 shadcn/UI 发起。它源于一种更深层次的愿望，即在依赖流行的用户界面库的同时，一直难以提供独特的设计，因此也难以提供独特的用户体验。

此外，在服务器上渲染组件以提高性能和用户体验的趋势，也阻止了 CSS-in-JS 解决方案（如 Styled Components 和 Emotion）的使用，因为它们通过执行 JavaScript 来输出 CSS，将所有性能负担都放在了客户端 / 浏览器上。新出现的 CSS-in-JS 解决方案（如 StyleX）通过编译为实用工具优先 CSS，缓解了这一问题。

我们很好奇，在这一趋势下会出现哪些新的用户界面库和 CSS 范例。我们已经看到了无头 UI 库（如带有 shadcn/UI 的 Radix）和实用优先 CSS（如 Tailwind）的崛起，但如果没有替代方案（如 vanilla-extract、PandaCSS、CVA）的出现，我们就不是网络开发者了。

当我们踏上 2024 年的征程，拥抱令人兴奋的网络开发趋势时，我相信你和我一样充满热情。随着人们对性能的普遍关注，很明显，我们正在迈向一个由浏览器中卓越的用户体验所创造的未来。