2021 年 Gatsby 与 Next.js 对比——是什么、为什么以及何时？

相似之处——为什么要比较？

服务器端渲染 vs 静态生成

盖茨比做得好吗？

盖茨比做得不好的地方是什么？

Next.js 的优势是什么？

Next.js 做得不好的地方是什么？

结论

2019 年，我决定写一篇名为“Gatsby 与 Next.js——是什么、为什么以及何时？”的文章，因为缺乏资源来总结哪个 React 框架最适合用于哪些情况。我记得自己早期研究过这两个工具，尝试阅读文章来比较它们的优缺点，当时我心想：“好吧，很酷，但我不知道它们getInitialProps是什么或能做什么。”“GraphQL 能给我带来什么好处？”我相信很多人都有同样的感受。

我的方法相当简洁，我想正因为如此，它一直是我浏览量最多的文章……至少是有史以来。

这篇文章在 Twitter 上仍然经常被分享，在 DEV.to（我最初发布它的地方）上的浏览量也刚刚超过 76000。然而，正如 Javascript 的惯例，几乎在我发布这篇文章后不久，它就过时了。

所以，一年多过去了，Gatsby 和 Next 都更加成熟了，我打算再次尝试，但会根据 2021 年的情况进行更新。仍然会尽可能地避免使用专业术语。希望你喜欢！

相似之处——为什么要比较？

首先，我将回顾一下基础知识。Gatsby 和 Next.js 都是 React 的框架，除非你一直生活在与世隔绝的地方，否则 React 是一个用于构建界面的 JavaScript 库。
在这方面并没有太大的变化，正如我在第一篇文章中提到的：

Gatsby 和 Next 都致力于奠定 React 应用的基础，并为您提供构建应用程序的指导方法。您现在创建 React 应用时可能使用的是样板，create-react-app它为您创建了所有基本功能和工具。相比之下，这两个框架将为您创建应用程序奠定基础——它们不属于样板，而是工具包，不仅奠定了基础，还会为您提供一套说明，指导您如何用一个装满合适工具的工具包来建造好房子。

总结一下：

• create-react-app- 奠定 React 项目的基础。剩下的就交给你了。

• Gatsby & Next - 奠定 React 项目的基础。提供如何在其基础上构建的指南以及一套工具。

是的，与 2019 年一样，它们非常相似，因为它们各自：

• 提供样板应用程序。
• 生成性能极佳、可访问且 SEO 友好的网站。
• 开箱即用地创建单页应用程序。
• 拥有非常棒的开发体验。

服务器端渲染 vs 静态生成

在第一篇文章中，我开始描述“服务器端渲染”（SSR）和“静态生成”（SSG）网站之间的区别，原因是 Next 只允许您构建服务器端渲染的页面，而 Gatsby 是一个静态站点生成器。

在撰写本文时，Gatsby 在构建时生成纯 HTML/CSS/JS ，并且无需服务器。而 Next 在运行时创建 HTML/CSS/JS ，因此每次收到新请求时，它都会从服务器创建一个新的 HTML 页面。

但遗憾的是，情况已经改变！

从 Next.js 9.3 版本开始，您可以选择页面预渲染的方式 - 使用静态生成或服务器端渲染。更多信息，请参阅 Next 官方文档 --> https://nextjs.org/docs/basic-features/pages#pre-rendering。

这改变了一切，因为可以说，除了数据获取方法（我稍后会谈到）之外，这才是这两个工具之间最大的区别。事实上，我在上一篇文章中说过，如果你的网站规模较小，那么使用 Gatsby（SSG）是合理的；如果你的应用程序规模较大，内容丰富，那么使用 Next（SSR）是合理的。但现在情况已经不同了。

因此，理解本文其余部分的最佳方式是更详细地介绍每个框架的优点和缺点。

盖茨比做得好吗？

GraphQL

使用 Gatsby 构建网站时，您可以通过名为 GraphQL 的查询语言访问数据。GraphQL 最初由 Facebook 于 2012 年创建，最初用于公司内部的移动应用程序。GraphQL 的优势在于它本质上允许特定数据获取，而 Facebook 发现这有助于减少网络负载。

GraphQL 服务器为前端提供了预定义的“模式”，允许客户端只提取相关信息和想要查询的字段，而不是像 REST 那样，将所有数据（无论相​​关与否）都从 API 中传递给客户端。这需要更多的人力。

以下是 GraphQL 查询的一个示例：

{
  site {
    siteMetadata {
      title
    }
  }
}

它返回的是：

{
  "site": {
    "siteMetadata": {
      "title": "Jamees' Shitty Website"
    }
  }
}

如您所见，我只指定了需要从 siteMetadata 获取标题，但实际上 siteMetadata 对象包含更多信息。您可以具体指定需要哪些信息。

GraphQL 作为查询语言的优势显而易见，它在各种应用中越来越受欢迎。Gatsby 也提供了这项功能，让快速上手这项技术变得相对容易，这真是太好了。

插件

在我看来，Gatsby 最酷的地方在于它庞大的“插件”生态系统。- https://www.gatsbyjs.com/plugins
它们是预制的 Node.js 包，允许你将预置的功能插入到你的网站中。本质上，它们是其他开发者编写的、用于完成特定功能的代码。

比如说，我想在我的网站上展示我的 Instagram 动态，向大家展示我超棒的办公桌和我最近吃的美味佳肴。有一个插件可以做到！复杂性早就解决了，只需安装插件并将其添加到网站配置中即可。我无需访问 Instagram 文档并生成 API 密钥和密码，这节省了时间。哦，真是省时省力。当然，也省了不少复杂性！

这很酷，因为它能让即使是最菜的开发者也能搭建并运行一个真正能实现目标的网站。我总是说，最好的学习方式就是实践，能够快速搭建并运行一个网站真的非常有成就感。

主题和启动器

除了庞大的插件生态系统之外，Gatsby 还拥有社区创建的大量“启动器”和“主题”。

这些是开发人员已经创建好的预建网站，有些甚至通过插件进行了样式设计和功能添加。所以，如果我想创建一个商店，我会找到一个相关的入门模板或主题，其中包含所需的功能——购物车、Stripe 链接等等。这真的很酷，我经常用，虽然不是出于专业目的，但是为了练习和了解它的工作原理。

盖茨比做得不好的地方是什么？

可以说，盖茨比最大的优点也是其最大的缺点。

事实上，它对于您应该如何获取数据有着如此强烈的主观意见，并且它非常关注插件生态系统，这意味着它通常很难摆脱这些。

虽然插件可以帮助开发者快速上手，但即使是设置基本功能，安装相同的插件也变成了一项重复的工作。当然，你可以构建自己的启动器，但即便如此，它也会比其他工具更复杂。

我经常发现自己想创建一个没有现成插件的功能。为了处理一个在非 Gatsby 应用中可以快速实现的小众功能，我不得不从头创建一个插件，这让事情变得更加复杂。开发人员最终不得不在文件中四处寻找gatsby-node.js并创建自定义的 Webpack 配置，这感觉很不直观。

还有——GraphQL……虽然它无疑很简洁，但在这种情况下，它失去了一个主要用途。正如我在文章前面提到的，GraphQL 是为了解决过度获取的问题，但 Gatsby 的核心业务是静态站点，这意味着从 API 中获取所有数据不会对运行时造成任何扩展。诚然，这在构建时会稍微花费一些时间，但为了灵活性，这似乎是值得的。

我在上一篇文章中说过，Gatsby 更适合小型应用程序，因为如果数据量巨大，你很可能会想要实现服务器端渲染。在这种情况下，GraphQL 几乎就像用大锤砸核桃一样（我个人拙见）。

值得庆幸的是，Gatsby 已经意识到了这一点，并在其文档中发布了“不使用 GraphQL 使用 Gatsby”一文。但这个解决方案只是权宜之计，而且他们竭力说服你不使用他们的数据层会带来“利弊”。

虽然这不一定会影响到该工具，但 Gatsby 团队一些高级成员对待承包商的方式引发了一些争议。这引发了巨大的混乱，以至于团队不得不向社区写一封公开信道歉 - https://www.gatsbyjs.com/blog/open-letter-to-gatsby-community/。

虽然这是一个感人的举动，但它掩盖了社区中正在讨论的许多问题。社区在早期对 Gatsby 来说也非常重要，如果你以某种方式为代码库做出贡献，你就会被邀请加入社区，成为他们 GitHub 页面的成员，并获得 Gatsby 特色礼品。Gatsby 团队会进行知识共享，并倾听使用该工具的软件工程师的真实需求。我知道它不可扩展，但关闭社区确实有点令人失望，而且想到一些员工对工作条件感到不满，这无疑让人感到不快。

Next.js 的优势是什么？

灵活性

去年这个时候，Next 的主要卖点在于它的灵活性。它不会强迫开发者陷入插件和 GraphQL 的生态系统。让 Next.js 能够在单个项目中在构建时（SSG）或请求时（SSR）预渲染页面，并让开发者选择其中一种并在两者之间切换，这极大地提升了灵活性。

你的项目很可能会随着时间的推移而发生变化。你可能会想添加一些之前从未考虑过的复杂性——而你认为 SSR 是实现这一目标的最佳方式。这很好 :) 这在 Gatsby 中是不可能的，所以在启动项目时就考虑可扩展性，如果项目有任何扩展的可能性，那么选择更灵活的解决方案就非常有意义。

SSG 功能确实很好！

听说 Next 团队正在开发静态生成网站功能时，我一开始还挺担心的。这跟他们最初的设想相差甚远，不过可以说，静态生成网站 (SSG) 的功能比 SSR 的功能要好得多。

使用文件系统路由简直是梦想成真（Next 在专注于 SSR 时就做到了），而且目前还没有 GraphQL 的踪影（当然，除非你想用它！）。如果你导出一个getStaticProps从页面调用的异步函数，Next.js 会在构建时使用 返回的 props 预渲染此页面getStaticProps。甚至还有一个名为“增量静态生成”的功能，这意味着你可以在运行时注册新的静态页面。一切都经过深思熟虑，他们也没有忘记那些在新功能添加之前就使用该工具进行 SSR 的用户。

开发者体验

Next.js 文档可能是我读过的最好的文档之一。快速上手非常容易，他们还包含一个基于游戏化的部分（通过回答测验问题和完成任务，在学习指南的过程中积累积分），这对于各个能力水平的人来说都是一个非常棒的补充。我希望看到其他项目也能如此专注于帮助人们快速上手！

Vercel 团队在解决痛点方面做得非常积极。如果你在 Twitter 上提到自己遇到了问题，几乎可以肯定团队中会有人提供解决方案。被倾听的感觉真好。Twitter 或社区其他地方出现的许多重大问题都会自动创建为工单。

Vercel 平台非常棒。

在撰写第一篇文章时，Next.JS 背后的公司名为“Zeit”。他们拥有多款不同的产品，其中最受欢迎的是 Now、Next 和 Hyper。如今，
他们已更名，并将平台的重点更多地放在部署上，并简化了工程师和工程团队的部署流程。这个平台本身就让我惊叹不已。

首先让我印象深刻的是一键域名分配功能。只需点击一下按钮，它就帮我搞定了所有事情，省去了我通常讨厌的一个流程。我使用这个平台越多，就越觉得印象深刻。部署非常简单，他们提供的项目分析功能也非常棒。一切都非常精致，用户友好。

虽然 Vercel 不一定是 Next.js 的一部分，但它也拥有一系列“无服务器函数”，即可部署到项目中的后端代码片段。这些代码片段接收 HTTP 请求并提供响应，允许您在前端代码库中插入并运行额外的功能。这些函数可以处理各种逻辑，包括用户身份验证、表单提交、数据库查询、自定义 Slack 命令等等。

与 Next.js 结合使用，这对于前端开发者来说简直是梦寐以求的软件包。我已经将大部分项目从 Netlify（同样出色）迁移过来，这样我就可以完全使用同一个“生态系统”来处理开发流程的方方面面。

Next.js 做得不好的地方是什么？

说实话，我很难写出这篇文章，因为如果不深入研究我希望看到的非常具体的技术特性，我唯一想到的就是，像使用 Gatsby 那样快速启动和运行某些东西会更加困难。

如果我浏览 Gatsby 的“Starter”库，我就可以选择一个我喜欢的博客模板，只需一行代码即可在本地安装，然后就可以开始运行了。
虽然像 Gatsby 那样过度依赖由主题/Starter 和可共享插件组成的生态系统无疑有些可惜，但能够选择已经启动、已配置好并包含少量 UI 的项目，即使只是为了学习不同的技术，也是一件很棒的事情。当然，Gatsby 也提供无服务器功能，但这些功能仅限于后端，与 Gatsby 所宣传的 UI 构建插件不同。

然而，越来越多的模板和启动项目正在涌现，最近添加的 Next.js 电子商务和 Next.js 虚拟事件就是一个很好的例子——而且 100% 值得指出的是“Nextra”，它是一个美味的文档生成器，但我希望看到更多选项，使项目快速轻松地启动和运行。

结论

对于任何想要构建 Web 应用的前端开发者来说，这两个框架绝对都是绝佳的选择。它们都能打造出性能卓越的网站，并带来良好的开发者体验。

我确实认为，自从我上次在 2019 年撰写评论以来，情况已经发生了变化。当时的选择更加明确，因为 Gatsby 擅长一件事（静态站点），而 Next 擅长另一件事（服务器端渲染），正如我上一篇文章所探讨的那样。

Next.js 更加通用且灵活。如果你的项目有潜力超越目前的规格，我建议你选择 Next。

但 Gatsby 可以让你更快地上手，用更少的代码实现更多功能。如果你想构建一个不太可能与现有规范有太大差异的东西，Gatsby 是一个不错的选择。

自 2019 年写作以来，我的使用方式也发生了变化。那时我更积极地编写代码和构建项目，而现在作为经理，我的编码时间要有限得多。2019 年，我是 Gatsby 的狂热用户，如果有人问我应该使用哪款，我都会推荐 Gatsby。

不过，就我个人而言，我通常会选择 Next。我这样做的理由是灵活性。对我来说，这更合理，因为随着时间的推移，我的项目可能会发生变化，而我希望有一个工具能够无缝地适应这种情况。此外，将所有内容放在一个平台上对我来说也很合理。它节省了我的时间和精力，同时也更容易跟上更新。