关于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我的项目。