编织的网

Jamstack 的一个有趣的悖论：其概念简单，却可能导致复杂性。

核心思想是：将预渲染的静态文件部署到擅长处理静态文件的 Web 托管服务（CDN）上。就这么简单。如果需要更多功能，则使用客户端 JavaScript，通常会与无服务器函数配合使用，因为这是 Jamstack 后端的理想搭档。Guillermo Rauch 最近在 Smashing Conf 上提到，Jamstack 并非严格意义上的“技术栈”，因为它对具体实现方式几乎没有限制。尽管我喜欢“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 网站。就像这个！它不是一个复杂的网络服务。它是一个静态网站生成器，内容位于 GitHub 仓库中，并使用 Netlify 部署。虽然 CSS-Tricks 可以做大约 100 件这个网站无法做到的事情，但它也有一些 CSS-Tricks 做不到的技巧，例如接受内容的拉取请求。

我觉得在我的所有案例中，我都选择了相当不错的方案。

1. 虽然 Matt 明显有动机来捍卫 WordPress 的方法，但我感觉这里的观点是真诚的；部分原因是 Automattic 投资于替代技术栈方法，并且 WordPress 和 Jamstack 并不相互排斥。我喜欢对此的回应，例如 Ohad Eder-Pressman 的公开信，其中也充满了带有动机但真诚的想法。

以上是编织的网的详细内容。更多信息请关注PHP中文网其他相关文章！