重塑 Jamstack：打造更简单、更强大的 Web 架构

本文最初发布于 THENEWSTACK。

图片来自 Unsplash，由 Rob Wicks 提供

随着互联网架构的发展，Jamstack已经变成了一个富有成效的存在，尽管有时会引起争议。2015 年，Netflix 首席执行官Matt Biilmann创造了这个词。它是由组成它的各种技术拼凑而成的——其中“JAM”来自 JavaScript、API 和 Markup。但是，经过几年的快速发展，2023 年，Jamstack——无论是作为一种架构还是作为一个开发社区——开始出现一些小问题。

对于开发人员来说，曾经简单直接的 JavaScript + API + Markup 方法已经变得越来越复杂。此外，去年，Netflix开始与Jamstack社区保持距离，关闭了 Jamstack Community Discord，并将宣传重点从 Jamstack 转向“可组合架构”主题。

那么 Jamstack 现在怎么样了？我与来自社区的不同成员进行了交谈，了解他们的关注点，以及他们将 Jamstack 推向下一阶段的想法。

Jamstack 的膨胀

首先，Cloud Cannon 首席执行官Mike Neumegen指出，Jamstack 复杂性增加的部分原因是其定义的扩展。

Neumegen 说：“由于开发人员在使用 Jamstack 时遇到了实现限制，所以其生态系统中的框架用更复杂的新方法解决了这些限制。后来，为了将这些新方法包含进来，Jamstack 持续扩展其定义。虽然这些方法为大型 Web 应用程序开发提供了强大的工具，但这种循环使 Jamstack 变成了现代 Web 架构的一个笼统术语。围绕 Jamstack 初始核心特性（比如可移植性、无配置缓存、预渲染、原子部署，以及最重要的简单性）的讨论少了。”

Pixel Point 开发者兼首席执行官Alex Barashkov也认为，复杂性增加已经成为 Jamstack 面临的一个问题。Barashkov 说：“Jamstack 提供了灵活性，但是 JavaScript 工具的范围太广了。选择合适的工具需要花费不少的时间，因为你需要确保它们不会消失，并且将来更新时不会有问题。鉴于有些东西在 Ruby on Rails 或 PHP 中更容易实现，Jamstack 社区正在不断地通过创新解决方案来弥合这些差距。”

其他开发人员提到了 Jamstack 开发的膨胀，并提出需要更简洁、更实用的方法。来自挪威的兼职开发大使Benedicte Raae说，“对于 Jamstack 的概念/架构，其扩展需求可能并不像人们想象的那么普遍，很少有 Web 项目需要这些工具提供的扩展。我刚刚和一个在奥斯陆拥有 300 个本地客户的团队交谈过……他们不需要超快的、全球复制的边缘计算之类的东西。也许他们只需要一把手动螺丝刀，而不是电钻。”

Jamstack 的 What、When、Why 和 How

Postman API API Client 主管Dustin Schau认为，就连“Jamstack”这个术语也已经成为问题的一部分。他说，“据我观察，一个主要问题是，人们并没有真正地理解这个术语。JAM （JavaScript、API、Markup）非常不精确，任何技术栈都可以说成是这个术语的具象。举个具体的例子，我记得，当 Next.js 将自己定位为 Jamstack 时，它完全是在服务器端渲染的，而且是在框架支持静态导出之前。一个令人困惑的术语就是存在这样的风险，它可能被用来迷惑开发人员或市场，因为从技术上讲，它是由 JavaScript、API 和 Markup 组成的，但那没有体现 Jamstack 的原则。”

与我交谈过的其他开发人员也表示，Jamstack 的表达力越来越弱。它是一个笼统的术语，让开发人员和整个行业感到困惑。演讲者兼独立开发大使Stefan Judis说，“在过去几年里，‘Jamstack’这个词变得毫无意义，其传递的信息和定义从 CDN 提供的静态和预渲染 HTML 转变为（Netflix 现在在其网站上描述的）‘一种将 Web 体验层与数据和业务逻辑分离的架构方法，为的是提高灵活性、可扩展性、性能和可维护性’。这种重新包装缺乏差异化和独特性。对我来说，Jamstack 成了利用 API、SaaS 和边缘计算的‘现代 Web 开发’的代名词。”

下一代 Jamstack

虽然 Jamstack 当前面临着上述问题和挑战，但与我交谈过的开发人员也相信，Jamstack 的底层架构会得到改进和增强，并提出了一些需要改进的、有助于 Jamstack 后续发展的领域。

Barashkov 说，“从技术的角度来看，Jamstack 需要跟上技术发展的趋势，比如 React 服务器组件（RSC）和 HTTP 流。Jamstack 应该为开发人员提供使用这些现代工具和库的直接建议。我相信，Jamstack 应该变得更加简单且特性鲜明，使得项目启动更快、更简单，而不必每次都从头开始。这种方法有助于加快开发过程，使项目更加一致、高效。”

消除那种复杂性，使 Jamstack 回归简洁明了的本源，是我与之交谈过的开发者之间的共鸣。为开发人员提供更多关于 Jamstack 最佳实践的指导，并清楚地定义 Jamstack 是什么——同样重要的是，它不是什么——也是一些得到很多支持的主题。

Neumegen（他的公司 Cloud Cannon 赞助了正在崛起的 Web 框架Eleventy）说，“Jamstack 一词是 2015 年被创造出来的。它倡导通过一种更简单的 Web 开发方法来应对单体系统的复杂性。近十年后，Jamstack 已经发展到面临自身复杂性挑战的地步。最好的改进是回归 Jamstack 的基本原则：预渲染内容并将前后端分离。它不必适合每个用例或吸引每个开发人员，这完全没问题。Jamstack 应该是 Web 开发简单性的拥护者。”

和 Neumegan 一样，Schau 强调说，Jamstack 成功的核心要素仍在，但他也指出，降低复杂性和提高性能将有助于 Jamstack 继续朝着积极的方向发展。

Schau 说：“不管是以前还是现在，Jamstack 的架构优势对那些关注性能和简单性的团队来说仍然是有益的。像 Astro（还有 Gatsby）这样的伟大工具完全符合我所认为的 Jamstack 原则的主要价值主张。因此，如果你的业务可以通过静态生成的、提供少量交互性的网站来维持运转，那么我强烈建议你的团队默认使用更简单但性能更高的工具来构建。”

未来之路：性能卓越、简单清晰

Neumegen 认为，要解决 Jamstack 的推广和信息传递问题，就需要提供更严格的 Jamstack 定义，遵守该定义的核心原则，明确说明 Jamstack 方法的优缺点，创建管理术语和社区的基金会，并提供一个社区活动空间。事实上，Cloud Cannon 最近创建了一个网站TheFutureOfJamstack.org，并在上面分享了他们对 Jamstack 下一步发展的想法和观点，以及该架构应该或不应该向哪发展。

Neumegen 说，“那是基础。从那里我们可以开始社区的重建。”

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://thenewstack.io/the-state-of-jamstack-developers-want-return-to-simplicity/