JAMstack？更像是SHAMstack。

我非常喜欢整个 JAMstack 的理念。 它似乎是一场健康的网络运动。 我非常期待即将举行的两场 会议。

在所有网络趋势中，#jamstack 似乎是最不令人后悔的。

— Chris Coyier (@chriscoyier) 2019年5月22日

不过，我觉得这个首字母缩略词可能并没有完全体现其精髓。 当然，我并不是建议我们更改它。 一旦这样的事物站稳脚跟，我发现最好顺其自然。 与无服务器的情况一样。 哎呀，这个网站的名字也相当… 不怎么样。

对我来说，JAMstack 最重要的部分根植于静态文件托管的概念。 静态文件托管是所有功能的基础。 它打开了许多大门，例如

• 所有内容都可以通过CDN托管。 就像他们所说的“边缘”。 甚至HTML（JAMstack 中的 M 也指标记）也可以通过CDN托管，否则你无法做到这一点。 这为你提供了惊人的速度基础，并鼓励你在构建过程中保持这种速度。
• 项目感觉更容易使用。 Git clone、npm install、build。 部署是 dist 文件夹的 git push 操作。 例如，Netlify 为你提供的每个构建都提供了一个 URL，即使是在你正在处理的分支上也是如此，这一点非常酷。 这是因为部署本质上是不变的。 在特定时间点的一组文件。
• 云函数非常棒。 因为你没有传统的服务器端语言可供使用，所以当确实需要服务器端代码时，你可以使用云函数来构建它——无论如何，这都是一种很酷的架构方式，并且与所有这些都非常契合。

不要以为，“哦，JAMstack 只是针对 Jekyll 博客”，或者诸如此类。 确实，静态网站生成器 非常符合 JAMstack 的特点，并且 JAMstack 非常鼓励尽可能多地预构建标记（这有利于速度和SEO等），但预构建标记并不是必需的。

我甚至可以说，一个客户端 JavaScript 驱动的应用程序，它提供一个<div id="root"></div>和一个 JavaScript 包，该包命中API并构建网站，仍然是一个 JAMstack 网站。 它仍然是静态托管的（可能是），并且云函数提供数据。

我会说“是”。

也许多一点服务器端渲染会很好，但出于各种原因，对于获得 JAMstack 徽章来说，它并不是必需的。

— Chris Coyier (@chriscoyier) 2019年5月22日

但只要你使用 JAMstack，就会鼓励你在这些静态文件中放入更多内容。 通过这种方式，它鼓励在可能的情况下使用静态内容。 我会说“服务器端渲染”（SSR），因为这是常用术语，但它超越了这个。 它不是服务器端语言根据请求生成标记；而是在部署之前，在构建步骤中提前构建的。 再一次，它不是必需的，只是鼓励的。

因此，我们有静态托管的HTML，以及我们所有其他文件（例如 CSS、图像等）也都是静态的。 然后

• JAMstack 中的 J 是 JavaScript。
• JAMstack 中的 A 是API。

它们有点类似。 你的 JavaScript 文件是静态托管的。 它们运行，如果需要，它们会与API通信。 一个常见的示例可能是 GraphQL 端点提供一些内容。

这里一个有趣的变化是，你可以将这些东西混合使用。 换句话说，你可以预构建一些标记，然后等待 JavaScript 和API调用其他部分。 想象一个电子商务网站，它有一个主页和十几页其他页面，你可以完全预构建它们，然后还有一个包含数千种产品的目录，静态生成这些产品是不切实际的（太慢了）。 它们只是一个单一的脚手架模板，通过客户端 API 调用来完善自身。

因此，如果我们要创建一个新的首字母缩略词，也许我们会将静态托管包含在其中，并将 JavaScript 和API合并为 API，这样我们就有了…

Static Hosting、APIs 和 Markup，或者 SHAMstack。 呃 😬 也许不行。