Jamstack 的语义

过去一年，围绕“Jamstack”一词的定义出现了健康的争论，因为该定义被扩展到涵盖新的用例。我最近在 “静态与动态与 Jamstack：界限何在？” 文章中发布了我对 Jamstack 定义的看法。在本文中，我想探讨 Jamstack 的演变及其对该术语的意义。

开发者在 Jamstack 术语出现之前很久就开始创建静态网站。最常见的用例是让开发者轻松地在 GitHub Pages 上托管他们的博客或开源文档。一些先驱者在静态网站上推动了更大的商业项目，但这在今天并不像现在那么普遍。

静态网站被认为是有限的——90 年代的旧技术。为什么有远见的公司想要使用这种古老的网站构建方式？Phil Hawksworth 在 他关于静态是一个负荷词的 IJS 演讲中准确地指出了这一点。

我们是在谈论静态体验，还是静态架构？

潜在的歧义非常令人困惑，尤其是对于非开发者而言。90 年代的静态网站与现代静态网站不同。有新的技术值得让静态网站重获关注。

• JavaScript 已发展成为一种功能强大的语言，用于在浏览器中构建应用程序。Gmail 于 2004 年推出，是第一个大量使用 Ajax 的主流应用程序。
• 静态网站生成器 (SSG) 带来了许多动态网站的优势，例如布局和将内容与代码分离。 Jekyll 是第一个广受欢迎的 SSG，于 2008 年推出。
• CDN 曾经是只有大型企业才能负担得起的技术。当 AWS Cloudfront 于 2008 年推出时，您可以几分钟内设置一个 CDN，而且在小规模情况下，它只需花费几美元。
• Git 工作流程以及围绕它构建的 CI/CD 工具，使容易出错的 FTP 部署成为过去。
• 生态系统——有 越来越多的独立工具 可以添加到静态网站中，以实现额外的功能，从搜索和电子商务到数据库、评论等。

Jamstack 帮助改变了人们对静态网站的看法。而静态网站的转变风向正是 Matt Biilmann 在 2016 年创造 Jamstack 这一术语的原因。突然之间，我们有了能够体现现代静态网站优势的词语，没有静态的包袱。 Cassidy Williams 做了 很棒的 Jamstack 核心思想概述

Jamstack 是关于以与移动应用程序相同的方式构建 Web 应用程序：UI 被编译，然后根据需要拉取数据。

Jamstack 特别是引起了许多 WordPress 开发者的共鸣。来自复杂主题和插件 API 的世界，SSG 带来的简洁性和控制力令人耳目一新。运动开始了，一个社区围绕着 Jamstack 的解耦方法形成了。

随着 Jamstack 的普及，项目的大小和复杂度也在不断增加。我们看到 Jamstack 的原则超越了网站，并进入了 Web 应用程序，我们很快达到了静态网站能够完成的范围的技术极限。平台添加了新功能和工作流程来扩展 Jamstack 原则，让更大、更复杂的应用程序可以采用 Jamstack 方法。

我很高兴能与 CloudCannon 一起参与这场演变。我们正在看到开发者构建 Web 软件方式的重大转变。一个欣欣向荣的专业工具和平台生态系统正在让前端开发者能够做更多的事情，以及让复杂的应用程序驻留在边缘。

我的担心是我们无法就 Jamstack 的实际含义达成一致。我们有简洁的定义，可以清楚地界定什么是 Jamstack，什么不是 Jamstack。这篇文章中列出了我个人最喜欢的定义。我们看到“Jamstack”一词被用于越来越多的动态行为。社区中有些人支持这种用法，而有些人则不赞成。歧义和感知是创造这个词语的最初原因，我们现在有陷入循环的风险。

对于 Jamstack 社区来说，这是一个难题，因为“Jamstack”的原始含义与该词的新、演变的、更具动态性的用法之间存在大量交叉。我自己也感到矛盾，因为我喜欢将 Jamstack 原则应用于更动态的方法。我曾短暂地考虑过使用“Jamstack”来描述静态用法，而使用“Jamstack++”来描述更动态的用法。但很快意识到这可能会造成比解决问题更多的混乱。

Matt Biilmann 对此做出了准确的总结，即 Netlify 发布的分布式持久渲染 (DPR)

对于任何技术来说，最难的部分不是建立简洁性，而是随着时间的推移保护它。

这完美地捕捉了我的想法。了解到如果我用 Jamstack 方法构建一个新项目，我并不受限，这令人安心。如果我的网站变得很大，或者我需要动态行为，我有很多选择。如果没有这些选择，Jamstack 将被视为用于小型用例的有限技术。另一方面，我们越强调这些更动态的解决方案，就越远离最初创造 Jamstack 运动的优雅简洁。

DPR 是一项激动人心的新技术。它是针对预构建大型网站这一痛苦限制的优雅解决方案。对于一个拥有 10 万个页面的网站，我会权衡是否预构建其中一部分页面，让剩下的页面在第一次被请求时按需构建，从而显著减少构建时间吗？当然，我会这么做！这是一个有意义的权衡。

我一直都在思考 DPR 如何适应 Jamstack 的整体格局，主要是因为它处于边缘。无论您是将它包含在 Jamstack 框架中，还是将其排除在外，都会产生连锁反应。

Sean Davis 有一个 Jamstack 定义 我很喜欢。

Jamstack 是一种架构，用于从边缘原子化构建和交付预编译的、解耦的前端 Web 项目。

这与我认为 Jamstack 的核心价值观相呼应。如果我们要将 DPR 纳入这个定义，就需要进行一些调整。

Jamstack 是一种架构，用于原子化构建和交付预编译（或按需生成的网页，但前提是这是第一次请求，然后将其持久化）、解耦的前端 Web 项目，并从边缘交付。

官方的 Jamstack 定义更适合 DPR

Jamstack 是 Web 的新型标准架构。使用 Git 工作流程和现代构建工具，预渲染的内容被提供给 CDN，并通过 API 和无服务器函数实现动态化。

DPR 或者使用无服务器函数交付内容，或者通过 CDN 作为静态文件交付内容，因此它符合该定义。

看到定义随着时间的推移发生了变化，这很有意思。在 2020 年底之前，官方的 Jamstack 定义（当时直接发布在 Jamstack.org 上）如下。

通过预渲染文件并直接从 CDN 提供服务，提供快速安全的网站和应用程序，无需管理或运行 Web 服务器。

技术随着时间推移而发展，语言也是如此，因此看到定义调整以跟上时代步伐，这很好。将“无服务器”纳入定义一方面是合理的，因为该技术正变得越来越容易被前端开发者使用（他们占 Jamstack 受众的主体）。另一方面，它违背了预渲染和解耦的 Jamstack 核心原则。我们是否也需要更新这些核心原则？

我仍然在处理所有这些想法和观点。我非常喜欢 Jamstack，它作为静态网站生成器发展的重大催化剂，让我们有了一种语言来谈论预渲染和解耦网站的方法。展望未来，我看到了 Jamstack 可以发展的五个方向。

1. Jamstack 仍然保留其原始含义，即预渲染和解耦。更具动态性的、受 Jamstack 启发的方法将获得自己的名称。
2. Jamstack 正在发展，定义和原则正在扩展。因此，其含义可能会变得更加模糊。
3. Jamstack 是社区的名称。它是一套指南，没有硬性的规则。
4. Jamstack 消除了静态的包袱，我们可以谈论静态网站、混合网站和动态网站。
5. Jamstack 变得足够主流，我们可以简单地称之为现代 Web 开发。

所有这些阵营中都有不同方向的人在努力，导致社区中出现很多困惑和讨论。明确的是，这个社区的人们对这种构建网站的方法充满热情。坦率地说，我对这个领域正在发生的创新感到非常兴奋。我们需要的是共识和前进的道路。没有这一点，我相信，无论好坏，我们最终会得到选项 3、4 和 5 的混合。