Jamstack 有点讽刺。
概念很简单：将预渲染的静态文件放到专门用于此的 Web 托管 (CDN) 上。就是这样。如果需要更多功能，从那里开始的任何操作都将使用客户端 JavaScript 完成，它很可能与无服务器函数进行通信，因为这是后端 Jamstack 的精神伴侣。我听到 Guillermo Rauch 前几天在 Smashing Conf 上说，它并非真正的“堆栈”，因为它在您所做的事情上几乎完全是非强制性的。虽然我喜欢 Jamstack 这个词，但这也很公平。
讽刺的是，虽然概念很简单，但这种简单性可能是复杂性的原因。
Netlify，这家主要推动 Jamstack 的公司，意识到了这一点。他们知道，如果没有具有后端语言的后端服务器，像基本联系表单这样的东西就会变得很复杂。我们必须想出另一种方法来处理该表单，而不是进入无脑解决问题的领域。因此，他们 为您解决了这个问题（以及其他问题，例如身份验证和无服务器函数）。但是，有 许多其他公司 想要成为您机器中的齿轮。
这仅仅是其中一个潜在的复杂之处。您将使用什么作为 CMS 或其他数据存储？您的构建流程是什么样的？您如何查看内容更改的预览？您如何进行身份验证？如果您需要一些花哨的日历小部件怎么办？如果您想卖东西怎么办？网站可以做任何事情，Jamstack 都能提供解决方案 - 只是将所有这些解决方案组合在一起会让人感觉支离破碎，而且可能令人困惑。
Dave 最近玩了 Eleventy + Tailwind + Netlify CMS（这是 Jamstack 风格的），他说感觉就像赶牛。
因此，我的小混搭原本只应该包含 3 种技术，却最终让我接触了大约 20 种不同的技术，让我在午夜后挖掘了第 n 级依赖项的源代码。如果我想要表达对当今 Web 开发的不满，那就是这样。您想使用三种工具，但您必须知道如何使用二十种工具。如果模块和组件就像乐高积木一样，那么这就像把整个盒子里的积木都倒在地上，只为了找到您需要的一块小积木。
“我们编织的错综复杂的网络”，确实如此。
在 Richard MacManus 和 Matt Mullenweg 之间的对话¹ 中，Richard 引用了 Matt 的话：
您可以将十几个服务拼凑在一起，每个服务都有自己的帐户和账单，每月花费数百美元，才能获得类似的结果，而您只需每月花费几美元就可以使用 WordPress 在共享主机上获得相同的结果。”他说。“而且它会更加脆弱，因为链条的强度取决于最薄弱的环节。您将不同的工具集、登录、计费、托管链式连接在一起……任何部分出现故障都会破坏整个流程。
如果我正在考虑将 Jamstack 用于某个特定项目，而且总共真的有十二种服务，我可能会重新考虑，尤其是如果我可以使用 WordPress 等工具，并将它缩减为一种服务。Jamstack 还有很多其他合理的批评，尤其是因为它还处于早期阶段。例如，“带有预览功能的 CMS” 的故事并不怎么好，而这恰恰是您在使用 WordPress 时根本不会考虑的功能，因为它显然拥有该功能。
而且 Jamstack 可以做一些让我珍惜的事情，这些事情远远领先于时代。基于 Git 的部署？所有网站都应该拥有该功能。拉取请求的预览？太棒了。小于 100 毫秒的首次请求？求之不得。无需费心缓存？太好了。赶上吧，其他堆栈。
我的意思是，这里有一些选择需要权衡。您通过做您可能一直在做的事情来实现这一点：穿上您的成人裤子，思考您的项目需要什么，然后选择最佳选项。
我有一些生产环境中的 WordPress 网站。就像这个网站！很棒！
我有一些生产环境中的 Jamstack 网站。比如 这个网站！ 它不是一个复杂的 Web 服务。它是一个静态网站生成器，GitHub 仓库中的内容通过 Netlify 部署。虽然 CSS-Tricks 可以做大约 100 件事，而这个网站做不了，但它有一些 CSS-Tricks 做不了的技巧，比如 接受内容的拉取请求。
我觉得自己在所有情况下都选择了非常好的方案。
我认为您应该尝试一下 Publii，它是一款很棒的本地静态 CMS。
我想知道 Jamstack 是否存在一些“局部最优”问题，即我们专注于这种特定模式并不断完善它，而没有考虑它可能并不总是最佳选择（正如本文指出的那样）。
这就是我个人喜欢 Next.js 的原因，它既支持“传统”的静态方法，也支持动态服务器端渲染，甚至（据我了解）包含两种方法混合的混合应用程序。
是的。这就是我目前投入时间和精力的领域。
我同意……
Nextjs + Vercel 似乎领先一步？
我同意这篇文章的观点。我目前在 Jamstack 中遇到的最大问题是，如果我想做的事情不仅仅是几个静态页面和一些动态片段，那么我需要支付一些创业公司服务的费用，这些服务使用胶带将漏洞修补起来。而且所有这些小公司都有不确定的未来，就像大多数创业公司一样，我最终将把网站的重要部分（包括托管和表单）托付给几家可能在 2-3 年内都不复存在的公司。
因此，JamStack 和 WordPress 之间的斗争开始了。JamStack 很棒，但目前的情况使其成为开发人员的理想选择。对于那些编码经验不足或没有编码经验的人来说，WordPress 是一个不错的选择。
是的，许多 Jamstack 项目从“哇，太简单了，太棒了！”变成了“哎呀，我们怎么最终要将十项服务拼凑在一起才能让它正常工作？”
这就是静态 WordPress 产品和服务可能有助于弥合差距的地方。我指的是 WP 的无头方法，这种方法很酷，但失去了 WP 提供的许多好处，比如您提到的预览功能。相反，这些服务允许用户像往常一样使用 WP，并获得 CMS、构建、预览等所有功能，然后将其部署到 Jamstack/静态架构中。一个例子是 Strattic（我是首席执行官），它是一个针对 WP 的静态托管和发布平台，因此我们的用户可以像往常一样管理他们的 WP 网站，然后单击一个按钮将其部署到静态环境中。
如果我说错了，请纠正我，我真的很想看到一篇关于这个主题的文章
仅仅放置一些静态文件并仅依赖客户端 JS 的概念的问题在于，最终结果无法被大多数机器人抓取。
我说大多数是因为 Google 最近才开始处理 JavaScript。但大多数抓取工具仍然无法处理，它们期望从服务器检索到的内容包含所有必要的数据。
如果您没有服务器端渲染，则不会发生这种情况。
Jamstack 如何解决这个问题，如果没有服务器动态渲染页面内容？
Jamstack 在人们眼中的印象如何变化真是有趣。我觉得早期都是“Jamstack 仅适用于静态网站生成器”，而静态网站生成器对于 SEO 来说非常棒。我认为，如果您确实关心 SEO，那么担心完全使用客户端渲染是完全合理的。我会说，如果您真的关心 SEO，请找到一种方法来确保您的内容标记在对 HTML 的第一次请求中就存在。尽可能多地预渲染。找到一种方法。看看这种新型的“边缘处理程序”/“边缘工作者”，我认为这将是一个巨大的概念。您可以在 HTML 下来之前，在 CDN 级别执行诸如 Ajax 请求之类的操作。这是一个实现动态操作而不损害 SEO 的绝佳机会。