关于 Jamstack 的 5 个误解

Jamstack 并不一定新鲜。该术语是在 2016 年正式创造的，但它所描述的技术和架构早已存在。Jamstack 最近获得了巨大的关注，关于它的文章出现在各大网站和出版物中，新的专注于 Jamstack 的 活动、新闻通讯、播客等等也相继出现。作为一个密切关注它的人，我甚至看到 Twitter 上对它进行了很多讨论，其中很多来自刚接触这个概念的人。

这种热潮似乎也带来了批评。一些批评是合理的，我将在稍后谈到其中的一些，但其他批评似乎是基于关于 Jamstack 的一些普遍误解，而这些误解一直存在，这就是我要首先解决的问题。所以让我们看看我遇到的五个关于 Jamstack 的常见误解，并揭穿它们。与许多误解一样，它们往往基于一些真相，但却导致了错误的结论。

误解 1：它们只是静态网站的重新包装

JAMStack 99.9% 是品牌，0.1% 是实质。😳😆 https://#/nxoEVQ43oE

— Nicole Sullivan – Black Lives Matter (@stubbornella) 2020 年 2 月 9 日

是的，正如我之前所述，“Jamstack”这个词可以说是对我们之前称为“静态网站”的重新包装。这并不是为了误导或向你出售尚未完全成型的产品——恰恰相反。术语“静态网站”早已失去了描述人们正在构建的内容的能力。使用静态网站生成器 (SSG) 构建的网站经常充满了各种动态内容和功能。

静态网站被认为主要是关于博客和文档，其中 UI 主要是固定的。交互的程度可能是嵌入式评论和联系表单。另一方面，Jamstack 网站具有诸如用户身份验证、动态内容、电子商务、用户生成内容之类的东西。

需要证据吗？一些使用 Jamstack 构建的知名公司和网站包括 Smashing Magazine、Sphero、Postman、Prima、Impossible Foods 和 TriNet，仅举几例。

误解 2：Jamstack 网站很脆弱

Jay Freestone，在 Jamstack 的问题：你可能需要后端

阅读 Smashing Magazine 的依赖项列表，就像服务等效于 node_modules，包括 Algolia、 GoCommerce、 GoTrue、 GoTell 以及各种 Netlify 服务，仅举几例。在 了解要外包什么（以及何时外包）方面，有巨大的价值，但有趣的是，注意到为了“回归基础”而引入的复杂性。这还没有提到依赖于如此多不同的第三方服务所带来的潜在脆弱性。

是的，为了实现将 Jamstack 与静态网站区分开来的动态功能，Jamstack 项目通常依赖于各种服务，包括第一方或第三方服务。有些人认为这使得 Jamstack 网站特别容易受到攻击，原因有两个。他们说，第一个是，如果任何一个部分出现故障，整个网站功能就会崩溃。第二个是，你的基础设施变得过于依赖你不拥有的工具和服务。

让我们来解决第一个论点。Jamstack 网站的大部分内容应该是预先渲染的。这意味着当用户访问网站时，页面及其大部分内容作为静态资产从 CDN 传递。这就是 Jamstack 的速度和安全性很高的原因。动态功能——例如购物车、身份验证、用户生成内容以及可能搜索——依靠无服务器函数和 API 的组合来工作。

广义地说，应用程序将调用一个无服务器函数，该函数充当后端，连接到 API。例如，如果我们的电子商务功能依赖于 Stripe 的 API 来工作，而 Stripe 宕机，那么是的，我们的电子商务功能将无法工作。但是，重要的是要注意，网站不会宕机。它可以通过告知用户问题的方式优雅地处理问题。依赖于 Stripe API 进行电子商务的服务器端渲染页面将面临相同的问题。假设服务器端渲染页面仍然异步地调用后端代码以进行支付，那么它与 Jamstack 版本一样脆弱，也一样不脆弱。另一方面，如果服务器端渲染实际上依赖于 API 调用，用户可能会卡在等待响应或收到错误（任何使用过网络的人都很熟悉这种情况）。

至于第二个论点，很难衡量 Jamstack Web 应用程序与服务器端渲染应用程序对第三方的依赖程度。如今的许多服务器端渲染应用程序仍然依赖于 API 来实现大量功能，因为这允许更快地开发，利用提供商的特定专业领域，可以将法律和其他合规性问题的责任转移出去等等。在这些情况下，服务器端渲染版本与 Jamstack 版本一样依赖，也一样不依赖。诚然，如果你的应用程序主要依赖于内部或自制的解决方案，那么情况可能会有所不同。

误解 3：编辑内容很困难

Kev Quirk，在 为什么我不使用静态网站生成器

不得不 SSH 到 Linux 机器上，然后在 Vim 中编辑文章，这似乎是关于在旅途中写作的 ridiculously high barrier for entry。如今，世界是移动优先的，无论你喜欢与否，在旅途中写作应该很容易。

这个问题感觉像是过去静态网站的遗留问题。需要明确的是，你不需要 SSH 到 Linux 机器上才能编辑你的网站内容。有 各种无头 CMS 选项，从完全免费和开源到为大型企业提供内容的商业产品。它们提供的编辑功能与任何传统 CMS 相媲美（我之前已经 讨论过）。重点是，没有理由手动编辑 Markdown、YAML 或 JSON 文件，即使是在你的博客边栏项目中。不确定如何将所有这些部分连接起来？我们也 有解决方案！

一个合理的批评是，无头 CMS 和构建过程可能会导致编辑的内容与网站上的更改之间脱节。在发布之前，或者没有一些复杂的构建预览过程，很难预览更改对实时网站的确切影响。这是生态系统正在解决的问题。像 Stackbit（我所在的公司）这样的公司正在构建工具，使这个过程变得无缝。

我们并不是唯一致力于解决这个问题的人。其他解决方案包括 TinaCMS 和 Gatsby Preview。我认为，在 Jamstack 之上运行类似 Wix 的工具上实现 WYSIWYG 编辑的简单性已经越来越近了。

误解 4：Jamstack 上的 SEO 很困难

Kym Ellis，在 Jamstack 对营销意味着什么

放弃插件的概念，选择一个“只是 HTML”的 Jamstack 网站，并不意味着你必须放弃功能，或者突然需要像前端开发人员一样了解代码才能管理网站及其内容。

近年来，我没有看到这个误解经常出现，我认为这主要是静态网站时代的遗留批评，在静态网站时代，管理与 SEO 相关的元数据涉及手动编辑基于 YAML 的 frontmatter。人们担心这样做会让 SEO 变得繁琐且难以维护，尤其是当你想要为每个生成的唯一页面注入不同的元数据，或者创建像 JSON-LD 这样的结构化数据时，而结构化数据对于增强你的搜索列表至关重要。

Jamstack 内容管理的进步通常解决了维护 SEO 元数据的复杂性。此外，由于页面是预渲染的，添加网站地图和 JSON-LD 相对简单，前提是所需的元数据存在。虽然预渲染使创建搜索引擎（即：Google）索引网站所需的资源变得容易，但它们也与 CDN 相结合，使实现提高网站排名所需的性能基准变得更容易。

基本上，Jamstack 在“技术 SEO”方面表现出色，同时也提供了必要的工具，使内容编辑器能够提供他们需要的关键字和其他元数据。要更全面地了解 Jamstack 和 SEO，我强烈建议查看 Bejamas 的 Jamstack SEO 指南。

神话 5：Jamstack 需要重量级的 JavaScript 框架

如果你试图向沉迷于时下流行框架的管理层推销简单的网站，那么一个宣传“JAMstack”优势的精美网站将非常有用。

– jdietrich，Hacker News

最近，Jamstack 似乎成为了前端 JavaScript 框架的代名词。确实，许多最知名的解决方案都依赖于前端框架，包括 Gatsby (React)、Next.js (React)、Nuxt (Vue)、VuePress (Vue)、Gridsome (Vue) 和 Scully (Angular)。这似乎加剧了对 Jamstack 中“J”的混淆。虽然它代表 JavaScript，但这并不意味着所有 Jamstack 解决方案都是基于 JavaScript 的，也不意味着它们都需要 npm 或 JavaScript 框架。

事实上，许多最常用的工具并非用 JavaScript 构建，最值得注意的是 Hugo (Go)、Jekyll (Ruby)、Pelican (Python) 和最近发布的 Bridgetown (Ruby)。同时，像 Eleventy 这样的工具是用 JavaScript 构建的，但并不依赖于 JavaScript 框架。这些工具都没有阻止使用 JavaScript 框架，但它们并不需要它。

这里的重点不是贬低 JavaScript 框架或使用它们的工具。这些都是很棒的工具，被许多开发人员成功使用。JavaScript 框架可以是功能非常强大的工具，能够简化一些非常复杂的任务。这里的重点仅仅是认为使用 Jamstack 需要 JavaScript 框架的想法是错误的——Jamstack 有 460 种口味！

我们可以改进的地方

就是这样吗？Jamstack 是一个理想的 Web 开发世界，在那里一切都不仅完美，而且完美地简单。不幸的是，并非如此。Jamstack 有很多合理的批评。

简单性

Sebastian De Deyne，与 玩转 JAMstack 后的想法（和疑虑）

根据我的经验，JAMstack（JavaScript、API 和标记）很棒，直到它不再很棒。当我需要添加一些动态内容时——那一天总会到来——我开始挠头。

说实话：开始使用 Jamstack 并不容易。当然，使用静态网站生成器构建博客或简单网站可能不会特别困难。但是，尝试构建一个带有任何动态内容的真实网站，事情很快就会变得复杂。

你通常会遇到大量完成任务的选择，这使得权衡利弊变得困难。Jamstack 的优点之一在于它没有规定性，但这可能使其看起来难以接近，让人们留下这样的印象：它可能不适合复杂的任务。

将服务捆绑在一起

同意。在昨天的 Web 中，你可以拿起乐器就开始演奏。今天，Web 开发感觉就像一个指挥试图将一个庞大的管弦乐队拉成一首和谐的歌曲——你必须理解每个音乐家各自的部分才能有机会成功。

— Brian Rinaldi (@remotesynth) 2020 年 5 月 1 日

当你真正开始构建那些动态功能时，你的网站可能会依赖于一系列服务和 API。你可能会调用一个无头 CMS 获取内容，一个调用 API 进行支付交易的无服务器函数，一个像 Algolia 这样的搜索服务等等。将所有这些部分整合在一起可能是一项非常复杂的任务。再加上每个部分通常都有自己的仪表板和 API/SDK 更新，事情会变得更加复杂。

这就是我认为像 Stackbit 这样的服务和像 RedwoodJS 这样的工具很重要的原因，因为它们将 Jamstack 网站背后的基础设施的各个部分整合在一起，使这些部分更容易构建和管理。

过度使用框架

在我看来，我们对现代前端开发中 JavaScript 框架的依赖最近受到了应有的怀疑。正如 Tim Kadlec 的这篇文章最近指出的那样，存在权衡取舍。正如我之前所说，你不需要 JavaScript 框架就可以在 Jamstack 中工作。

然而，这种印象的形成部分原因是如此多的 Jamstack 工具依赖于 JavaScript 框架，也部分原因是我们的 Jamstack 教学方式大多集中在使用框架上。我理解这样做的原因——许多 Jamstack 开发人员在 JavaScript 框架中很舒服，而且不可能教所有工具，所以你会选择你喜欢的那个。不过，我个人认为，Jamstack 的长期成功取决于它的灵活性，这意味着（尽管我对简单性的说法如上所述），我们需要展示它提供的各种解决方案——无论是否使用 JavaScript 框架。

从这里去哪里

天哪，你做到了！我知道我要说很多，可能比我开始写作时意识到的还要多，所以我不会用一个冗长的结论来烦你，只是想说，很明显，我从一个非常相信 Jamstack 价值的人的角度提出了这些神话，尽管它有缺陷！

如果你正在寻找一篇关于何时选择 Jamstack 而不是服务器端渲染以及何时不选择的优质文章，请查看 Chris Coyier 最近发布的文章 静态还是非静态？。