关于react.js:如何在2023年开启React项目

在这里，我想给你一个新的 React 我的项目入门的简要概述。我想反思一下长处和毛病，反思一下作为一个开发者所须要的技术水平，反思一下作为一个 React 开发者，每个启动我的项目都能为你提供哪些性能。最初，你将理解到针对不同需要的 3 种解决方案。

免责申明：从集体开发者的角度来看，我齐全反对 React 团队在其新文档中推动的框架 /SSR 议程。然而，我感觉最近的布告使 React 初学者和想采纳 React 的公司处于不利位置。因而，我想在这里给他们提供更多不同的抉择，作为逃生通道。

应用 Vite

Vite 是 create-react-app(CRA)的明确继承者，因为他们俩没有太大的区别。与 create-react-app（CRA）（应用 Webpack）相比，它的速度要快得多，因为它在后盾应用了esbuild。

与 create-react-app（CRA）雷同，Vite 依然偏向于创立单页应用程序（SPA），其客户端路由 / 渲染性能优于 SSR。然而，因为 SSR 现在正成为一个更重要的话题，因而它在 Vite 中作为了可选性能。

当我的项目来自 CRA 时，间接迁徙到 Vite 是很容易的。像 TypeScript、ESLint、SVG 和 SSR 这样的可选性能只需在 Vite 的 vite.config.js 文件中进行一些配置，除此之外还能够在一些特定性能文件中进行配置（如tsconfig）。

Vite 容许开发者在没有主意的框架下应用 React。开发者能够抉择互补的 React 库进行路由、数据获取、状态治理和测试。与所有的 React 框架相比，它不会强制你应用任何特定的 React 性能、库或配置（在我的项目层面）。

最初，Vite 激励初学者学习 React 和它的基本原理，而不被框架所分心。当 Vite 成为副驾驶时，初学者能够齐全专一于 React 和它的外围性能。相比之下，在框架环境中学习 React 时，React 简直成了副驾驶，而不得不遵循框架的意见（比方基于文件的路由）。

应用 Vite 的长处

• 简直能够间接代替 CRA
• 仍然对 SPA/CSR 敌对，但 SSR 是可选的
• 没有框架 / 公司的捆绑
• 轻量级

• 在性能层面上不与 React 一概而论

  • 因而专一于 React 自身，而不是一个框架
• 理解 React 基本原理的学习曲线比拟平缓

应用 Vite 的毛病

• 优先思考 SPA/CSR
• 没有框架反对

• 无奈应用 React 为集成框架提供的架构性能

  • 例如，React 服务端组件（RSC）

为什么可能不是 React 文档中的默认值

• 应用 SPA/CSR 而不是 SSR

• 技术捆绑使开发者无奈应用所有 React 性能

  • 例如，React 服务端组件（RSC）

• 不利于实现以下愿景

  • 领有一个 React 框架
  • 启用不同的渲染技术

  • 启用所有可用的 React 性能

    • 例如，React 服务端组件（RSC）

• 框架无关（这里指 React）

  • React 不是 Vite 的重点
  • Vue 的缔造者尤雨溪的观点

应用 Next

Next.js 作为一个框架是十分成熟的，因而当 React 开发者想在一个有主意的框架环境中应用 React 时，它是一个理智的抉择。它蕴含了许多个性（例如基于文件的路由）。如果 Next.js 不是你的菜，能够看看最近公布的 Remix 框架，它与 Next.js 的不同之处在于它专一于 web 规范。

Next.js 优先思考将服务端渲染（SSR）作为渲染技术。然而，它也能够用于动态网站生成（SSG）和客户端渲染（CSR）。在此基础上，还有一些更前沿的渲染技术，如增量式网站渲染（ISR）和 React 服务端组件（RSC）。是什么让这所有变得更加令人震惊：你能够在 Next.js 应用程序中混合和匹配渲染技术。尽管营销页面能够应用 SSG，但登录 / 注册背地的理论应用的 SSR。

不过，这么大量的新技术也是有代价的：不同的渲染技术会产生工程开销，框架会一直地钻研新的渲染技术，因而最终会扭转其优先级，而且不是所有的程序员都能跟上步调。只管 Next.js 在过来没有引入破坏性变动方面做得很好，但在将 JavaScript/React 渲染技术引入后端这个前沿畛域工作时，总会有新的规范 / 配置。

总的来说，尽管 Next.js 蕴含了许多个性（例如基于文件的路由），但它也有责任。尽管 React 自身（比方应用 Vite）放弃绝对稳固，但你必定会看到 Next.js 生态系统的变动，因为他们正带头将 React 带到服务器上。

Next 的长处

• 带有内置库的框架

• SSR 和许多其余渲染技术

  • 性能晋升（留神：如果解决正确的话）
  • 与 CSR 相比，SEO 失去改善

• Vercel 是领有大量资金的大公司

  • 与 React 外围团队严密单干
  • 有许多 React 外围团队的成员被雇佣
• 在前沿畛域耕耘

Next 的毛病

• 在前沿畛域耕耘
• 与应用 Vite 的 React 相比，开销 / 稳定性 / 可维护性较差

• 与应用 Vite 的 React 相比，学习曲线更平缓

  • 更多关注框架的细节，更少关注 React 自身

• 框架（和基础设施，例如在 Vercel 上部署）捆绑

  • 后者可能由 OpenNext 解决

为什么可能是 React 文档中的默认值

• 最成熟的框架，合乎 React 的框架议程
• SSR 是一等公民，合乎 React 的 SSR 议程

• 应用 React 的所有原始值

  • 例如，React 服务端组件（RSC）
• 不优先思考 ” 过期的 ”SPA/CSR
• 与 React 及其外围团队关系密切

• 与 React 的外围团队单干，在 Next 中实现新的性能

  • 并最终被 Meta/Facebook 应用

应用 Astro

Astro 容许开发人员创立以内容为重点的网站。因为它的群岛架构以及选择性混合，它默认给每个网站提供高效的性能。因而，SEO 相干的网站从应用 Astro 中获益。

从实现的角度来看，它偏向于多页面应用程序（MPA）的概念，而不是单页面应用程序（SPA）。因而，它完结了历史循环：从 MPA 是网站的次要类型（2010 年之前）到 SPA 被取代（2010-2020 年），再次回到 MPA（从而使 MPA 首先成为一个术语）。

Astro 是一个与框架（这里是指 React）无关的解决方案。因而，你能够应用 Astro 的内置组件语法或你抉择的框架（如 React）。尽管框架只是用于服务端的渲染，并没有裸露给客户端。只有当一个人决定将一个交互式群岛混合到客户端时，它才会获取所有必要的 JavaScript 代码到浏览器上。

对于以内容为重点的网站，Astro 被视为 Gatsby 的竞争对手。在过来的几年里，Gatsby 失去了与 Next 的间接竞争。在这场竞争中，人们可能过多地关注与 Next 的性能对等（如 SSR），因而对以内容为重点的网站真正重要的 DX 和性能的关注较少。这给了 Astro 一个机会，来作为可行的代替计划染指。

总之，只管 Next（有 SSR/SSG/ISR）或 Gatsby 也适宜以内容为重点的网站。不过 Astro 作为新的竞争对手，仿佛合乎以内容为重点的网站更具体的要求（比方性能、专一于内容制作）。

相比之下，Next 混合了渲染技术。因而，一个性能优化的营销页面能够在应用程序中实现，而理论的应用程序则暗藏在登录后。但依据 Astro 的基准，它的性能依然较差（不思考 RSC，因为还不稳固），因而我宁愿在古代 Monorepo 设置中混合应用 Next 和 Astro，以使应用程序和网站并存。

应用 Astro 的长处

• 以内容为重点的网站
• 性能
• SEO
• 框架无关（比方 React）

应用 Astro 的毛病

• 不为动静 web 应用程序做广告

为什么可能不是 React 文档中的默认值

• 框架无关

  • React 不是 Astro 的重点

• 与 React 的新性能不统一

  • 例如，React 服务器组件

    • 应用群岛架构，而不是选择性混合

• 每次点击链接都要从新加载整个页面

  • 因而不是最好的导航用户体验
  • 这些问题最终会在 RSC 的 Next 中失去更好的解决

• 相同，Gatsby 被列入了举荐启动程序的名单中

  • 一流的 React 解决方案
  • 在架构层面上与 React 的性能相整合
  • 与 React 外围团队有更严密的分割

更多抉择

• 应用 Parcel 取代 Vite
• Monorepo Setup（如 Turborepo），可选 Vite、Next 和 / 或 Astro。
• 用于 tRPC 的 create-t3-app
• 用于挪动端应用程序的 React Native/Expo
• 用于桌面端应用程序的 Tauri/Electron

用 React 以外的其余库启动 SSR 我的项目的抉择：

• SvelteKit
• SolidStart
• QwikCity

如何开启 React 我的项目

• 如果你开始学习 React（从教育者的角度），我倡议应用 Vite，因为它尽可能地靠近 React 的基本原理。如果你只想找一个轻量级的 SPA/CSR 解决方案，也是如此。

• 如果你想在 React 的根底上寻找一个有主意的框架，并蕴含几种渲染技术（和基础设施），我会举荐应用 Next，因为它是最成熟的解决方案，有所有的长处和毛病。

  • 如果 Next.js 不合乎你的需要，但你依然在寻找一个蕴含所有个性的 SSR 框架，请应用 Remix。
• 如果你想领有一个以内容为重点的网站，请查看应用 Astro 大节。

免责申明：在 2023 年写这篇博文与 2024 年写这篇博文可能齐全不同，届时 Next 的 App Router 和 RSC 会变得稳固，从而成为创立服务端 React 应用程序的现状。在我集体看来，这是一个转折点，它可能会推动 Next 成为所有之前列出的案例的一体化解决方案。

最终想法

尽管许多教育工作者可能会同意为 React 初学者提供一个更容易的终点（直到 RSC/Next 有更多的稳定性和更精简 / 整合的学习教训），但 React 文档中新的 ” 开始一个新的 React 我的项目 “ 局部反而使很多 React 初学者处于一个两难的地步。

• 产生了什么：过来征询 React 的初学者被指向旧的文档；但被告知应用带钩子的函数组件。
• 可能会产生什么：征询 React 的初学者被指向新的文档；但会被告知应用 Vite 而不是 Next。

总之，我为 React 团队提供新的文档感到高兴。然而，它随同着许多探讨，特地是围绕 React 启动我的项目的抉择。

只管每个人都隐约晓得 SSR 和框架正在成为古代 React 的高优先级，但对于许多人来说，没有看到 Vite 是从头开始创立一个 React 我的项目的最简略的办法，依然是一个惊喜（至多在 2023 年）。在 2024 年可能会有不同的状况，届时所有的基本要素（为初学者提供的 React/Next 交互式教程、Next13/RSX 的稳定性、对 RSC 优先利用的关注）都会存在，但当初 ” 如何创立一个新的 React 利用 ” 的转变，以及新的文档仿佛都很仓促。

从一个独自的开发者的角度来看，我很期待这次服务端的冒险会带给咱们什么。然而，我感觉当初初学者开始学习 React，就像他们在 React Hooks 公布时一样，因而这篇博文是为了提供更多样化的抉择来开启一个新的 React 我的项目。