比较 Gatsby 和 Next.js 在网站开发中的应用

乍一看，Gatsby 和 Next.js 可能非常相似。它们都是基于 React 的框架，都支持 SSR 和 SSG，并且拥有庞大的社区。我们在公司内部积极使用这两种技术，但我们认为它们更适合不同的用例。我经常被问到，为什么我们使用 Gatsby 而不是 Next.js 进行网站开发？本文将详细解释这一点。

选择网站开发技术时，我们需要牢记几个因素

发展速度
编辑经验
可维护性
可扩展性
定制

以下是两个框架的功能比较表。它们几乎一样，不是吗？

然而，这些细微的差别可能会对网站开发造成巨大的影响。

现在，让我们回顾一下网站需要什么，并检查框架如何处理相同的任务。

一切始于或终于 Favicon

每个网站都有一个简单的小东西。但是，为了兼容不同的用例、操作系统和浏览器，你通常需要多个尺寸——16x16、32x32、180x180、512x512 等等。如果你不需要关心它，那就太好了。

...有了 Gatsby，你就不需要

只需修改一行gatsby-config.js，即可上传基于 png/jpg/svg 格式的图标……就这样。Gatsby 将按照最佳实践生成一组相关的图标，无需任何额外工作即可优化图像。

...但是 Next.js 怎么样？

Next.js 对此没有推荐任何固定的方法。您可以尝试 Google 一下，看看答案有多么不同，例如这个 Stackoverflow 帖子。所有操作都必须手动完成——图像优化、调整图像大小、使用<Head>tag 嵌入合适的标签。您也可以选择使用类似这样的图标生成器服务。

图像优化已成未来

两者都具有很多神奇的功能，使用 sharp 库调整图像，支持 webp 和 avif 等现代图像文件格式，从而减小文件大小并加快网站加载速度。

两者都有各自的图像组件，next-image和，gatsby-image并且 API 类似。但也存在一些差异。

下一张图好看吗？

next-image仅仅是实际图像优化通过 API 路由进行的一个组件，它接受查询字符串参数并返回已处理的图像，例如，/_next/image?url=http://example.com/avatar.png&w=32&h=32

我喜欢这种架构，因为它在不使用反应组件的情况下使用优化图像方面也带来了额外的灵活性。

另外值得一提的是：next-image需要你指定图片的宽高，而从 CMS 获取数据时则不需要，除非你使用 CMS，layout="fill",但这样做之后，你需要手动处理图片包装器的逻辑。因此，为了避免布局偏移，你需要从 CMS 获取图片，获取其宽高，然后使用 CSS 的宽高比属性或 SVG hack 等技术来gatsby-image自动保持原始比例。

或者 gatsby-image 更好？

gatsby-image没有该 API 端点，而是使用其 graphql 数据层和不同的转换器插件的强大功能在后台完成神奇的操作。一切都开箱即用，无需额外配置。但还有一件事 Gatsby 可以做得更好 - 图像艺术指导。艺术指导旨在为不同屏幕尺寸定义多个图像 srcset，这些图像可以进行不同的裁剪和定位。典型的用例是当您有一个大图表（比如在主页上）但在移动设备上，如果我们只是缩小它就会太小。作为解决方案，您可以将带有增加图表标签的辅助图像传递给针对移动设备优化的 srcset。

CMS集成的重要性

为了获得最佳的客户体验，为编辑人员提供最大的灵活性以及可靠的CMS集成至关重要。在网站上，我们构建的每个单词和页面都可以通过CMS以及任何其他元数据（页面URL、元标签、og标签等）进行编辑。我们大多数情况下使用Headless WP，但有时也会使用Contentful、Strapi或Prismic，因此拥有一种灵活且直接的方式从不同平台获取数据至关重要。

Gatsby 和插件的强大功能

使用 Gatsby，集成只需安装插件并提供 API 密钥即可。无需处理 SDK 和钻研 API 文档。所有内容都将被提取并添加到统一的 Gatsby Graphql 层。插件种类繁多，几乎可以找到任何插件的源码。客户使用某个招聘平台，并希望在自己的网站上显示职位列表？没问题。如果他计划显示带有星数计数器的 Github 代码库列表，只需获取插件即可。数据将被添加到 Graphql，您无需担心理解各种 API 的学习曲线。

使用 gatsby-source-wordpress 插件通过 Gatsby Graphql 获取数据的示例

Next.js 定制方法

Next.js 没有插件生态系统，因此为了从 CMS 获取数据，我们必须寻找 SDK，学习 API，考虑该集成在网站不同页面上的可复用性，甚至可能为常见用例制作一些 SDK 封装器或 HOC。对于小型网站来说，这或许没问题，但对于大型网站来说，则需要花费一些时间思考整体数据获取架构和解决方案的可扩展性。

预览还是不预览？

好吧，我们先回过头来说，因为我敢肯定很多人根本不会费心给编辑器提供这个功能。预览功能意味着根据 CMS 的需求渲染特定页面，而无需在生产环境中发布。

如果您使用 Gatsby，它支持最流行的 CMS，并且能够无缝协作。您可以使用 Gatsby Cloud，预览服务器将自动创建，您只需将 CMS 指向正确的 URL 即可；或者，您也可以使用部署一个运行 Gatsby 的自托管版本GATSBY_ENABLE_REFRESH_ENDPOINT=true。以下是 Gatsby + Headless WP 协同工作的示例。

使用 Next.js 后，事情会变得更加复杂；请参阅官方文档。同样，您需要为每个计划预览的实体手动编写它，定义预览触发器的数据解析规则、稍后将获取哪些数据以及将渲染哪些数据。与使用 Gatsby 只需五分钟即可完成设置的情况不同，您将需要花费数小时才能获得可用的功能。

通过程序化页面生成为编辑器提供灵活性

Next.js 选项

为了获得一流的编辑器体验，编辑器必须负责定义在其上显示的 URL 和页面。让我们打破常规，先从 Next.js 开始。有几个选项可以实现或部分实现它。

1）硬编码动态子页面 URL，例如/post`，然后在组件中pages/post/[slug].js. For example, there is a slug field for a post on the CMS side, and you agree it will always be under the定义 getStaticPaths 。

2) 在根组件中编写一个通配符组件pages/[...path].js。然后编写一个额外的包装组件，其中包含将特定 URL 映射到特定组件的逻辑。这引发了很多问题，并大大增加了架构的复杂性。

3) 使用Faust - 一个基于 Next.js 构建、专门针对 WP 集成进行调优的框架。查看其源代码，你会发现他们正是按照选项 2 的方式做的，而且它非常复杂。而且它只适用于 WP。

盖茨比之 路

Gatsby 最初是作为 SSG 框架创建的，因此它具有一些强大的架构概念

1) 单点程序化页面生成gatsby-node.js。想象一下，这就像用自然语言告诉框架——“请从 CMS 获取所有页面，然后基于模板为每个 CMS 页面创建一个相关的 Gatsby 页面，并使其可通过 CMS 中定义的 URL 访问。” 因此，我们可以根据 CMS 中的数据为页面使用不同的模板。

2) 模板概念。将页面概念与模板分离，可以更轻松地定义硬编码的 URL 以及基于模板以编程方式创建的页面。

因此，您可以实现完全由 CMS 驱动的路由和页面创建，而无需担心代码中的复杂逻辑。

我们要求增量静态再生！

增量静态再生 (ISR) 允许您仅增量更新特定页面，而不是根据传入的更改重新构建所有页面。增量构建在技术上与 ISR 有所不同，但两者都试图解决同一个问题：通过增量更新页面来加快生产环境中的内容更新速度。Gatsby 自 v3 版本以来就一直支持增量构建，并借助不同的 CMS 集成和 Gatsby Cloud 积极使用它，只重建新的更新，这通常只需几秒钟。

Next.js 一直采用一种略有不同的方法，当 CMS 发生变更时，它不需要额外构建即可运行。相反，它允许你指定从缓存中获取页面的时间（以秒为单位），这样当第一个不幸的用户进入时，它就会去获取新数据。

最初，我考虑将其视为 Next.js 的一个缺点。这是一个需求量很大的功能，但在我撰写本文期间，他们引入了按需 ISR，该功能旨在解决这个问题，能够通过外部源调用重新验证缓存。截至 2 月 17 日，它被认为是 Beta 功能。

随处进行数据查询

Next.js 的另一个高需求功能是在组件级别（而非仅在父页面级别）查询类似的数据getServerSideProps。getStaticProps目前，您必须使用 props 或 stores/context 将数据从顶层组件传递到底层组件。React 18 和服务端组件在未来应该可以解决这个问题。

同时，在 Gatsby 项目中，你可以使用从任何地方从全局 graphql 层获取数据useStaticQuery。它简化了架构并允许你拥有可重用的组件。

非常外部的进口

NextJS 最近引入了这项功能，并且有迹象表明，它将为低代码/无代码解决方案与手写应用程序的结合带来巨大的优势。为了理解此功能，最好阅读这个 Framer 与 Next.js 结合使用的精彩示例。您可以在可视化编辑器中构建自定义组件，还可以用一些漂亮的动画包装它，然后只需一行代码即可将其导入项目：

这令人兴奋，并开启了许多未来的可能性。Gatsby 目前还不允许你这样做。所以，如果你想在项目中使用它，Next.js 可能是更好的选择。

站点地图在任何地方都适用

这两个框架都可以通过使用额外的库来处理这个问题。Gatsby 使用插件和极简配置来处理这个问题。对于 Next.js，库可以执行相同的操作，但需要执行额外的构建后脚本。

无智能 i18n

有趣的是，尽管这两个框架的实现看起来几乎相同，但 Next.js 的另一个名为“全局中间件”的功能使其更加强大。它允许你定义一个顶级中间件，并在边缘网络上执行例如国家/地区检测之类的操作，然后将用户替换或重定向到静态生成的页面。

概括

我们仍然推荐这两个框架用于网站开发，因为它们是非常可靠的解决方案。然而，Gatsby 在静态生成和插件生态系统支持的集成方面绝对更胜一筹。对我们来说，这些功能至关重要，我们也看到了 Gatsby 如何帮助我们更快地构建网站，使其更加灵活和易于维护。Next.js 是一个更面向动态的框架，只有当我需要在网站上添加额外的身份验证层，或者需要全局中间件功能来帮助处理国际化、A/B 测试或功能开关时，我才会使用它。这些功能当然很不错，但通常情况下，只有大型企业级技术公司能够负担得起这样的实验时，才会选择它们。

想了解更多关于 Gatsby、Next.js 以及构建高性能、视觉震撼网站的技巧吗？请在 Twitter 上关注我。

文章来源：https://dev.to/alex_barashkov/comparing-gatsby-and-nextjs-for-website-development-13b7