Jamstack CMS 的故事可以追溯到 90 年代。在本文中,我们沿着记忆之路走一趟,看看我们是如何获得今天拥有的现代 Jamstack CMS,以及它们在未来十年的发展方向。
世界上第一个网站是由在文本编辑器中创建的静态 HTML 文件制成的。虽然它看起来不起眼,但它为我们今天的网络奠定了基础。快进 30 年,网站技术发生了巨大变化——我们有图像、样式表、JavaScript、流视频、AJAX、动画、WebSockets、WebGL、CSS 中的圆角——不胜枚举。
90年代
在 90 年代,我们看到了两个用于静态站点的内容管理系统——1996 年的 Microsoft FrontPage和1997年的 Macromedia Dreamweaver。
这些桌面应用程序使工具更接近当今现代 Jamstack 内容管理系统。在仍然控制 HTML 的同时拖放网站组件的想法在当时是开创性的。
维护布局成为静态站点的一个特殊痛点。例如,假设您有一个网站并且想要更改您的导航。您需要在每个页面上进行更改。在这一点上,动态生成的网站已经通过包含解决了这个问题。
Dreamweaver 4 引入了可编辑区域,这是首次尝试将静态网站的内容与布局分开。现在,您可以管理更大的网站,甚至可以将内容编辑交给其他人,而不必担心他们会破坏网站的其余部分。
本地开发和部署之间的桥梁也是 Dreamweaver 开始通过集成 FTP解决的一个痛点。
00年代
在 2000 年代,我们对两个流行的博客发布平台进行了对决——2001年的MovableType和2003年的WordPress。这不仅是专有与开源的较量,也是静态与动态的较量。可以肯定地说 WordPress,现在为 40% 的互联网提供动力的平台赢得了这场战斗,但 MovableType 为未来的 Jamstack CMS 铺平了道路。
MovableType 是市场上最早的静态站点生成器之一,尽管该术语直到 2008 年才流行起来。 Ben 和 Mena Trott 之所以创建 MovableType,是因为“对现有博客 CMS 不满意——性能、稳定性”。直到今天,这两点都是从动态站点切换到静态站点的常见原因。
有趣的是,在 MoveableType 的文档中几乎没有提到静态站点。相反,他们会在任何更改后谈论“重建”网站。我想他们想要避免“静态”这个词的限制性认知。这与导致社区采用“Jamstack”一词的问题相同。
在 MovableType 之前,可以使用其他个人博客平台,例如Geocities、Blogger 和 Open Diary。但是,MovableType 是您可以免费下载并自行托管的首批广泛使用的平台之一。此外,他们在 2003 年推出了一个名为 TypePad 的托管版 MovableType,以与其他流行的云平台竞争。
使用 MovableType,您拥有管理博客所需的一切。您可以创建和更新博客文章,所有内容都是纯 HTML — 当时还没有开源 WYSIWYG 编辑器,而 Markdown 直到 2004 年才出现。
我们可以在这里看到现代 Jamstack CMS 的所有骨架。MovableType 确实是超前的。
2006 年,Denis Defreyne 尝试建立一个基于 Ruby 的博客平台,但遇到了性能问题——“只有 96 MB RAM 的 VPS,任何基于 Ruby 的 CMS 运行速度都非常慢。” 一年后,Denis 推出Nanoc,这是一个简化 MovableType 模型的静态站点生成器。Nanoc 删除了用户界面,取而代之的是您在命令行上运行的程序。
据我所知,这是第一个现代静态站点生成器,尽管我们距离创造这个词还有一年的时间。
Nanoc 有许多我们现在认为理所当然的静态站点生成器 (SSG) 功能:
- 布局使用 Ruby 的 ERB 模板语言创建布局元素。
- 页面元数据一个单独的 YAML 文件,用于存储页面的标题和其他元数据。前面的事情还不是一件事。
- Markdown 支持在 Markdown 中编写内容并在构建时将其转换为 HTML。
- 模板类似于 Hugo 原型的功能。
- 插件称为库;根据您自己的需要扩展静态站点生成器。
- Front matter:元数据不再存在于单独的文件中,现在您可以在文件顶部有一个小的 YAML 片段。
- Blog aware:使用 Markdown 文件创建帖子。Jekyll 将这些构建到一个数组中,您可以对其进行迭代和分页以创建博客。
10 年代
2012 年,Dave Cole 发表了一篇关于我们如何构建 CMS 免费网站的文章。这篇文章详细介绍了 Development Seed 如何将他们的网站从 Drupal 迁移到 Jekyll,以及他们如何使用Prose.io来管理内容。Development Seed 构建了Prose.io,让内容作者更容易为 Jekyll 网站做出贡献。
Prose.io 与您的 GitHub 存储库同步,并为日常内容任务提供简单的 GUI,例如更新前台内容、编写 Markdown、创建帖子和上传文件。此外,内容更新会保存回 GitHub,从而在开发人员和内容作者之间建立紧密的工作流程。
Prose 将 Jekyll 从一个供开发人员创建博客的工具转变为一个强大的内容发布平台。此外,它引发了十年的公司将静态站点生成器内容发布推向新的水平。
现在有数百种现代 Jamstack CMS可供选择,每种都有自己的优势和权衡。Jamstack CMS 通常采用以下三种方法之一来管理静态网站上的内容:
- SSG/CMS 包
SSG/CMS 包的缺点是它们捆绑在一起。您可能喜欢编辑体验,但讨厌网站生成部分。值得注意的是,您可以在其中一些平台上丢弃 SSG 部分,仅将其用作内容 API。
- 内容 API
当您运行 SSG 构建时,您可以从内容 API 下载内容并像处理数据文件一样与其进行交互。内容 API 的好处是您可以在许多不同的数字体验中重用内容。除此之外,您还可以管理大量内容并在内容之间建立深厚的关系。
缺点是您的内容存在于第三方,因此您在任何停机时间、API 更改或您与内容的交互方式方面都任其摆布。最后,由于编辑界面是从内容的最终用例中抽象出来的,因此 Content API 中的字段与您在网页上看到的呈现内容之间可能存在脱节。
示例:Contentful、Prismic、Strapi。
- 基于 GIT 的 CMS
基于 Git 的 CMS为非技术内容编写者带来了Git 工作流的所有功能。缺点是所有内容都在您的存储库中,因此如果您想在多个数字体验中重用内容,则需要在静态站点上构建 JSON 端点。托管存储库也有大约 2GB 的上限,因此如果您有很多资产,您可能需要使用 3rd 方服务来处理媒体。
示例:CloudCannon(免责声明:我是联合创始人)、Netlify CMS、Tina
Jamstack CMS 现在在哪里?
SSG 最初是供开发人员构建个人博客的工具。这是一种让开发人员完全控制的简单方法,但您需要对 Web 开发有基本的了解才能为网站做出贡献。在过去十年中,Jamstack和 Jamstack CMS的快速发展帮助推动 Jamstack 成为主流用例。这些用例包括:
- 文档
- 发展很快,有更多的时间来打磨。
- Markdown是一种出色的文档格式,使用良好的 CMS 使文档变得更加容易。
- 该站点将立即加载。
- 网站内容位于一个存储库中,允许开发人员社区提出改进建议。
- 电子商务
- 亚马逊著名的研究报告称,每延迟 100 毫秒,他们就会损失 1% 的销售额。Jamstack 站点通常是网络上最快的站点之一。
- 当电子商务网站停机时,它无法产生销售。Jamstack 站点中的移动部件要少得多,因此更容易保持在线状态。
- 电子商务网站不断迭代以提高转化率。开发人员体验是 Jamstack 的核心,允许开发人员快速做出和发布更改。
- 企业网站
借助 Jamstack 和 Jamstack CMS ,Netflix、Peloton和Intercom在其公司网站上的迭代速度更快。
- 大型博客
- 政府网站
digital.gov、Singapore Together和CIO.gov在 GitHub 上都有公共存储库,您可以浏览所做的每项更改或建议内容更新。
- 客户网站
Wilto Makes Food、Down Thyme、The Bottle Room Bar与世界领先的公司采用相同的 Jamstack 方法。
现代 Jamstack CMS 与WordPress Drupal其他流行的 CMS 相比如何?
概括地说,有两种方法可以使网站在线:
- 您选择一个模板,根据您的品牌对其进行自定义并输入您的内容。
- 您与设计师和开发人员合作创建一个定制网站。
- WordPress
在大多数关于 Jamstack 的文章中,您会发现一个特点超越WordPress 抛在脑后。人们经常谈论 WordPress 是如何缓慢、不安全和复杂的。我相信这是一个更基本的方法对话。我们经常谈论静态与动态,单体与解耦。WordPress 是最受欢迎的 CMS,因此它通常是被攻击目标。
事实是,您可以在使用 WordPress 作为 CMS 的同时享受 Jamstack 的好处。Shifter和Strattic等托管平台将您的 WordPress 网站变成静态网站。您还可以使用插件输出静态站点或使用WordPress 作为无头 CMS将内容填充到静态站点生成器中。
从 WordPress 迁移到 Jamstack CMS也相对简单。对于 Git CMS,您需要将博客文章和资产迁移到与您选择的静态站点生成器一起存在的 Markdown 文件。幸运的是,许多 SSG都有 导入 工具,可以轻松实现这一点。对于 Content API CMS,其中一些具有数据导入工具,否则,您始终可以编写脚本来从 WordPress 提取数据并将其保存到您的 Content API。
- Drupal
现代 Jamstack CMS 有大量关于这些小型网站的成功案例研究。对于更复杂的企业用例,我们有更少的例子。Jamstack 需要克服一些限制才能与大型 Drupal 安装竞争:
构建时间:使用静态站点生成器预构建站点需要时间。对于小型站点,构建可能需要几秒钟。一个拥有 10 万页的网站可能需要一个小时以上的时间来构建。在每次更改后等待一个小时来构建您的网站并不是一个可行的开发工作流程。
动态功能:大型、复杂的网站通常具有某种形式的动态行为。表单、评论、搜索和自定义 API 端点都是 Drupal 的基础。对于许多开发人员来说,如何在 Jamstack 站点上执行这些操作并不明显。
细粒度权限:Drupal 拥有丰富且可扩展的权限系统。大型网站拥有庞大的内容编辑团队,这需要深入的权限系统。
20年未来
Jamstack CMS 正处于令人兴奋的轨道上。但是,要成为企业建立网站的主流方式,还有很长的路要走。那么,要让 Jamstack 具有更广泛的吸引力,我们需要解决哪些问题?
- 直观的内容编辑
- 减少对开发人员的依赖
- 更好的发布工作流程
- 我们不能将代码差异放在内容编辑器之前。