如何在2023年开启React项目
<p>在这里，我想给你一个新的React项目入门的简要概述。我想反思一下优点和缺点，反思一下作为一个开发者所需要的技术水平，反思一下作为一个React开发者，每个启动项目都能为你提供哪些功能。最后，你将了解到针对不同需求的3种解决方案。</p><p><strong>免责声明</strong>：从个人开发者的角度来看，我完全支持React团队在其新文档中推动的框架/SSR议程。然而，我觉得最近的公告使React初学者和想采用React的公司处于不利地位。因此，我想在这里给他们提供更多不同的选择，作为逃生通道。</p>
<h2 id="使用vite">使用Vite</h2>
<p>Vite是create-react-app(CRA)的明确继承者，因为他们俩没有太大的区别。与create-react-app（CRA）（使用Webpack）相比，它的速度要快得多，因为它在后台使用了<code>esbuild</code>。</p>
<p><img src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fb845de756ec491da253ed7750fd8ed6~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>与create-react-app（CRA）相同，Vite仍然倾向于创建单页应用程序（SPA），其客户端路由/渲染功能优于SSR。然而，由于SSR如今正成为一个更重要的话题，因此它在Vite中作为了可选功能。</p>
<p><img src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/425d5dd9c6044867b3bfb06536049198~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>当项目来自CRA时，直接迁移到Vite是很容易的。像TypeScript、ESLint、SVG和SSR这样的可选功能只需在Vite的<code>vite.config.js</code>文件中进行一些配置，除此之外还可以在一些特定功能文件中进行配置（如<code>tsconfig</code>）。</p>
<p><img src="https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/69a013c020334ef18c8d6e9f17c4200f~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>Vite允许开发者在没有主见的框架下使用React。开发者可以选择互补的React库进行路由、数据获取、状态管理和测试。与所有的React框架相比，它不会强迫你使用任何特定的React功能、库或配置（在项目层面）。</p>
<p>最后，Vite鼓励初学者学习React和它的基本原理，而不被框架所分心。当Vite成为副驾驶时，初学者可以完全专注于React和它的核心功能。相比之下，在框架环境中学习React时，React几乎成了副驾驶，而不得不遵循框架的意见（比如基于文件的路由）。</p>
<h3 id="使用vite的优点">使用Vite的优点</h3>
<ul>
<li>
<p>几乎可以直接替代CRA</p>
</li>
<li>
<p>依然对SPA/CSR友好，但SSR是可选的</p>
</li>
<li>
<p>没有框架/公司的捆绑</p>
</li>
<li>
<p>轻量级</p>
</li>
<li>
<p>在功能层面上不与React混为一谈</p>
<ul>
<li>因此专注于React本身，而不是一个框架</li>
</ul>
</li>
<li>
<p>了解React基本原理的学习曲线比较平缓</p>
</li>
</ul>
<h3 id="使用vite的缺点">使用Vite的缺点</h3>
<ul>
<li>
<p>优先考虑SPA/CSR</p>
</li>
<li>
<p>没有框架支持</p>
</li>
<li>
<p>无法使用React为集成框架提供的架构功能</p>
<ul>
<li>例如，React服务端组件（RSC）</li>
</ul>
</li>
</ul>
<h3 id="为什么可能不是react文档中的默认值">为什么可能不是React文档中的默认值</h3>
<ul>
<li>
<p>使用SPA/CSR而不是SSR</p>
</li>
<li>
<p>技术捆绑使开发者无法使用所有React功能</p>
<ul>
<li>例如，React服务端组件（RSC）</li>
</ul>
</li>
<li>
<p>不利于实现以下愿景</p>
<ul>
<li>
<p>拥有一个React框架</p>
</li>
<li>
<p>启用不同的渲染技术</p>
</li>
<li>
<p>启用所有可用的React功能</p>
<ul>
<li>例如，React服务端组件（RSC）</li>
</ul>
</li>
</ul>
</li>
<li>
<p>框架无关（这里指React）</p>
<ul>
<li>React不是Vite的重点</li>
<li>Vue的缔造者尤雨溪的观点</li>
</ul>
</li>
</ul>
<h2 id="使用next">使用Next</h2>
<p>Next.js作为一个框架是非常成熟的，因此当React开发者想在一个有主见的框架环境中使用React时，它是一个明智的选择。它包含了许多特性（例如基于文件的路由）。如果Next.js不是你的菜，可以看看最近发布的Remix框架，它与Next.js的不同之处在于它专注于web标准。</p>
<p><img src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/25f104929a64482097228508f406415f~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>Next.js优先考虑将服务端渲染（SSR）作为渲染技术。然而，它也可以用于静态网站生成（SSG）和客户端渲染（CSR）。在此基础上，还有一些更前沿的渲染技术，如增量式网站渲染（ISR）和React服务端组件（RSC）。是什么让这一切变得更加令人震惊：你可以在Next.js应用程序中混合和匹配渲染技术。虽然营销页面可以使用SSG，但登录/注册背后的实际使用的SSR。</p>
<p><img src="https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a672c9fa04a34d7f8ab216cb86fb9355~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>不过，这么大量的新技术也是有代价的：不同的渲染技术会产生工程开销，框架会不断地研究新的渲染技术，因此最终会改变其优先级，而且不是所有的程序员都能跟上步伐。尽管Next.js在过去没有引入破坏性变化方面做得很好，但在将JavaScript/React渲染技术引入后端这个前沿领域工作时，总会有新的标准/配置。</p>
<p>总的来说，虽然Next.js包含了许多特性（例如基于文件的路由），但它也有责任。虽然React本身（比如使用Vite）保持相对稳定，但你肯定会看到Next.js生态系统的变化，因为他们正带头将React带到服务器上。</p>
<h3 id="next的优点">Next的优点</h3>
<ul>
<li>
<p>带有内置库的框架</p>
</li>
<li>
<p>SSR和许多其他渲染技术</p>
<ul>
<li>性能提升（注意：如果处理正确的话）</li>
<li>与CSR相比，SEO得到改善</li>
</ul>
</li>
<li>
<p>Vercel是拥有大量资金的大公司</p>
<ul>
<li>与React核心团队紧密合作</li>
<li>有许多React核心团队的成员被雇佣</li>
</ul>
</li>
<li>
<p>在前沿领域耕耘</p>
</li>
</ul>
<h3 id="next的缺点">Next的缺点</h3>
<ul>
<li>
<p>在前沿领域耕耘</p>
</li>
<li>
<p>与使用Vite的React相比，开销/稳定性/可维护性较差</p>
</li>
<li>
<p>与使用Vite的React相比，学习曲线更陡峭</p>
<ul>
<li>更多关注框架的细节，更少关注React本身</li>
</ul>
</li>
<li>
<p>框架（和基础设施，例如在Vercel上部署）捆绑</p>
<ul>
<li>后者可能由OpenNext解决</li>
</ul>
</li>
</ul>
<h3 id="为什么可能是react文档中的默认值">为什么可能是React文档中的默认值</h3>
<ul>
<li>
<p>最成熟的框架，符合React的框架议程</p>
</li>
<li>
<p>SSR是一等公民，符合React的SSR议程</p>
</li>
<li>
<p>使用React的所有原始值</p>
<ul>
<li>例如，React服务端组件（RSC）</li>
</ul>
</li>
<li>
<p>不优先考虑"过时的"SPA/CSR</p>
</li>
<li>
<p>与React及其核心团队关系密切</p>
</li>
<li>
<p>与React的核心团队合作，在Next中实现新的功能</p>
<ul>
<li>并最终被Meta/Facebook使用</li>
</ul>
</li>
</ul>
<h2 id="使用astro">使用Astro</h2>
<p>Astro允许开发人员创建以内容为重点的网站。由于它的群岛架构以及选择性混合，它默认给每个网站提供高效的性能。因此，SEO相关的网站从使用Astro中获益。</p>
<p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/714d1d30b09a414d87e6183303a3e1a2~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>从实现的角度来看，它倾向于多页面应用程序（MPA）的概念，而不是单页面应用程序（SPA）。因此，它结束了历史循环：从MPA是网站的主要类型（2010年之前）到SPA被取代（2010-2020年），再次回到MPA（从而使MPA首先成为一个术语）。</p>
<p>Astro是一个与框架（这里是指React）无关的解决方案。因此，你可以使用Astro的内置组件语法或你选择的框架（如React）。虽然框架只是用于服务端的渲染，并没有暴露给客户端。只有当一个人决定将一个交互式群岛混合到客户端时，它才会获取所有必要的JavaScript代码到浏览器上。</p>
<p><img src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3f5464e82dda4ba085198c1b549371c6~tplv-k3u1fbpfcp-watermark.image?)"></p>
<p>对于以内容为重点的网站，Astro被视为Gatsby的竞争对手。在过去的几年里，Gatsby失去了与Next的直接竞争。在这场竞争中，人们可能过多地关注与Next的功能对等（如SSR），因此对以内容为重点的网站真正重要的DX和性能的关注较少。这给了Astro一个机会，来作为可行的替代方案介入。</p>
<p>总之，尽管Next（有SSR/SSG/ISR）或Gatsby也适合以内容为重点的网站。不过Astro作为新的竞争对手，似乎符合以内容为重点的网站更具体的要求（比如性能、专注于内容制作）。</p>
<p>相比之下，Next混合了渲染技术。因此，一个性能优化的营销页面可以在应用程序中实现，而实际的应用程序则隐藏在登录后。但根据Astro的基准，它的性能仍然较差（不考虑RSC，因为还不稳定），因此我宁愿在现代Monorepo设置中混合使用Next和Astro，以使应用程序和网站并存。</p>
<h3 id="使用astro的优点">使用Astro的优点</h3>
<ul>
<li>以内容为重点的网站</li>
<li>性能</li>
<li>SEO</li>
<li>框架无关（比如React）</li>
</ul>
<h3 id="使用astro的缺点">使用Astro的缺点</h3>
<ul>
<li>不为动态web应用程序做广告</li>
</ul>
<h3 id="为什么可能不是react文档中的默认值-1">为什么可能不是React文档中的默认值</h3>
<ul>
<li>
<p>框架无关</p>
<ul>
<li>React不是Astro的重点</li>
</ul>
</li>
<li>
<p>与React的新功能不一致</p>
<ul>
<li>
<p>例如，React服务器组件</p>
<ul>
<li>使用群岛架构，而不是选择性混合</li>
</ul>
</li>
</ul>
</li>
<li>
<p>每次点击链接都要重新加载整个页面</p>
<ul>
<li>因此不是最好的导航用户体验</li>
<li>这些问题最终会在RSC的Next中得到更好的解决</li>
</ul>
</li>
<li>
<p>相反，Gatsby被列入了推荐启动程序的名单中</p>
<ul>
<li>一流的React解决方案</li>
<li>在架构层面上与React的功能相整合</li>
<li>与React核心团队有更紧密的联系</li>
</ul>
</li>
</ul>
<h2 id="更多选择">更多选择</h2>
<ul>
<li>使用Parcel取代Vite</li>
<li>Monorepo Setup（如Turborepo），可选Vite、Next和/或Astro。</li>
<li>用于tRPC的create-t3-app</li>
<li>用于移动端应用程序的React Native/Expo</li>
<li>用于桌面端应用程序的Tauri/Electron</li>
</ul>
<p>用React以外的其他库启动SSR项目的选择：</p>
<ul>
<li>SvelteKit</li>
<li>SolidStart</li>
<li>QwikCity</li>
</ul>
<h2 id="如何开启react项目">如何开启React项目</h2>
<ul>
<li>
<p>如果你开始学习React（从教育者的角度），我建议使用Vite，因为它尽可能地接近React的基本原理。如果你只想找一个轻量级的SPA/CSR解决方案，也是如此。</p>
</li>
<li>
<p>如果你想在React的基础上寻找一个有主见的框架，并包含几种渲染技术（和基础设施），我会推荐使用Next，因为它是最成熟的解决方案，有所有的优点和缺点。</p>
<ul>
<li>如果Next.js不符合你的需求，但你仍然在寻找一个包含所有特性的SSR框架，请使用Remix。</li>
</ul>
</li>
<li>
<p>如果你想拥有一个以内容为重点的网站，请查看使用Astro小节。</p>
</li>
</ul>
<p><strong>免责声明</strong>：在2023年写这篇博文与2024年写这篇博文可能完全不同，届时Next的App Router和RSC会变得稳定，从而成为创建服务端React应用程序的现状。在我个人看来，这是一个转折点，它可能会推动Next成为所有之前列出的案例的一体化解决方案。</p>
<h2 id="最终想法">最终想法</h2>
<p>虽然许多教育工作者可能会赞同为React初学者提供一个更容易的起点（直到RSC/Next有更多的稳定性和更精简/整合的学习经验），但React文档中新的"开始一个新的React项目 "部分反而使很多React初学者处于一个两难的境地。</p>
<ul>
<li>发生了什么：过去咨询React的初学者被指向旧的文档；但被告知使用带钩子的函数组件。</li>
<li>可能会发生什么：咨询React的初学者被指向新的文档；但会被告知使用Vite而不是Next。</li>
</ul>
<p>总之，我为React团队提供新的文档感到高兴。然而，它伴随着许多讨论，特别是围绕React启动项目的选择。</p>
<p>尽管每个人都隐约知道SSR和框架正在成为现代React的高优先级，但对于许多人来说，没有看到Vite是从头开始创建一个React项目的最简单的方法，仍然是一个惊喜（至少在2023年）。在2024年可能会有不同的情况，届时所有的基本要素（为初学者提供的React/Next交互式教程、Next13/RSX的稳定性、对RSC优先应用的关注）都会存在，但现在"如何创建一个新的React应用"的转变，以及新的文档似乎都很仓促。</p>
<p>从一个单独的开发者的角度来看，我很期待这次服务端的冒险会带给我们什么。然而，我觉得现在初学者开始学习React，就像他们在React Hooks发布时一样，因此这篇博文是为了提供更多样化的选择来开启一个新的React项目。</p><br><br>
来源：https://www.cnblogs.com/chuckQu/p/17461839.html
頁:
[1]