JAMstack CMS 终于成熟了！

本文基于 Brian 在 Connect.Tech 2019 上的演讲。该演讲的幻灯片以及演讲者笔记可 下载。

根据我的经验，开发人员通常很容易理解 JAMstack 的优势。网站速度更快，因为资源是静态的，并通过 CDN 提供服务。网站更安全，因为没有框架、应用服务器或数据库可供入侵。开发和部署可以得到优化，因为构成堆栈的所有部分都是解耦的。等等。

开发人员较难理解的是，这通常需要为创建和编辑内容的人员做出一些权衡。传统的单体内容管理系统经常受到开发人员的嘲笑（是的，甚至包括 WordPress），他们试图将工具弯曲到自己的意愿以满足项目需求，从而感到沮丧。但是，直到最近，JAMstack 主要只是将这种负担转嫁给了非技术性的内容创建者和编辑者。

由开发者为开发者打造

静态网站生成器（例如 Jekyll、Hugo 和 Gatsby 等工具）的普及度大幅提升，很大程度上是因为开发人员将其用于项目。它们已成为博客、文档或简单静态页面等内容的常用解决方案。总的来说，这些网站是由开发人员创建、维护的，并且内容主要由开发人员撰写和编辑。

2015 年，我在为 O’Reilly 撰写的一份报告中首次写到了这些工具，当时我这么说：

以防万一这一点尚不清楚，我想强调的是，静态网站生成器是为开发人员构建的。这从网站的开发一直持续到添加内容。非开发人员不太可能觉得在 Markdown 中使用 YAML 或 JSON 前端内容（即大多数静态网站引擎内容或文件开头包含的元数据）编写内容很舒服。非技术用户也不太可能觉得编辑 YAML 或 JSON 数据文件很舒服。

——我本人（为 O’Reilly 撰写的 2015 年静态网站生成器报告）

两年后，我与我的朋友 Raymond Camden 为 O’Reilly 撰写了一本书 讨论了这个主题，但情况并没有太大变化。当时有一些处于非常早期阶段的工具，包括 Jekyll Admin 和 Netlify CMS，但它们尚未成熟到能够与内容编辑者在 WordPress 等工具中习惯使用的 WYSIWYG 工具相竞争的地步。

相比之下，静态 CMS 的编辑体验仍然需要了解 Markdown 和其他标记语言（YAML、Liquid 等）。

可以肯定地说，无论当时架构的技术优点如何，从内容编辑的角度来看，这套工具集还没有准备好进行主流应用。

尴尬的青春期

在随后的两年里，一些趋势的结合开始使 JAMstack 成为具有非技术编辑的主流内容网站的可行解决方案。第一个趋势是，静态 CMS 发展成为我们现在通常所说的基于 Git 的 CMS 解决方案。第二个趋势是，无头、API 优先的 CMS 作为企业采用的解决方案而兴起。

让我们先看看第一个趋势……嗯……首先。Netlify CMS 是 Netlify 的一个开源项目，它是基于 Git 的 CMS 的一个例子。基于 Git 的 CMS 不会像传统 CMS 那样存储您的内容，但它具有可以理解如何编辑 Markdown、YAML、JSON 和构成 JAMstack 网站的其他格式的工具。这为内容编辑者提供了他们感到舒适的工具，但在幕后，他们的内容更改只是提交回存储库，从而强制重新构建网站。虽然 Netlify CMS 安装在网站本身，但其他流行的基于 Git 的 CMS 选项（如 Forestry）是基于 Web 的。
.

无头、API 优先的 CMS 的功能更像传统 CMS 中的编辑体验。它不仅提供创建和编辑内容的工具，还存储这些内容。但是，它通过 API 将这些内容提供给前端——任何前端。虽然不受任何方式限制于 JAMstack，但 API 优先的 CMS 与其配合使用效果很好，因为内容的创建和管理与前端内容的显示是分开的。此外，许多 API 优先的 CMS 提供与一些最广泛使用的静态网站生成器的预构建集成。流行的 API 优先选项包括 Contentful、DatoCMS 和 Sanity。

HeadlessCMS.org 是由 Netlify 维护的一个网站，它包含所有可用工具（基于 Git 和 API 优先）的综合列表。要详细了解选择基于 Git 的 CMS 与 API 优先的 CMS 之间的区别、优缺点，请查看 Bejamas 发布的这篇文章。

基于 Git 和 API 优先的无头 CMS 选项都开始为非技术内容编辑者提供在后端创建内容所需的工具。这些“青春期”的尴尬之处在于，工具仍然与前端脱节。这使得很难看到您在后端所做的更改将如何影响前端，直到这些更改真正提交到存储库或通过 API 推送到实时环境。再加上重建的时间成本，您将获得一种不太理想的编辑体验，在这种体验中，错误更容易出现在实时网站上。

展望未来

那么，当 JAMstack CMS 终于成熟时，未来会是什么样子呢？好吧，我们在今年的 JAMstack_conf_sf 上看到了这一点。巧合的是，有两个演示文稿展示了新的工具，这些工具正在将内容编辑体验带到前端，让内容编辑者能够看到他们正在更改的内容、更改的外观以及它们将如何影响网站的布局。

第一个 演示文稿 是由 Forestry 的 Scott Gallant 发布的。在其中，他介绍了 Forestry 的一个新的开源项目，名为 TinaCMS，它为使用基于 Git 的 CMS 和 Gatsby 或 Next.js（这两个都是基于 React 的工具）的网站的前端带来了 WYSIWYG 样式的内容编辑体验。

第二个 演示文稿 是由 Stackbit 的 Ohad Eder-Pressman 发布的（完全披露：我在 Stackbit 担任开发者布道师），该演示文稿介绍了一套即将推出的工具，称为 Stackbit Live。Stackbit Live 旨在与 CMS 和静态网站生成器无关，同时仍允许对 JAMstack 网站进行页面内编辑和预览。

这两个工具都证明了我们已经达到了一个“JAMstack + 无头”架构真正可以替代传统 CMS 的阶段。我相信我们已经达到了一个临界点，我们不再为了获得良好的开发人员体验而牺牲内容作者不佳的编辑体验。到 2020 年，JAMstack CMS 将正式完全成熟。👩🏽‍🎓