关于jamstack的5个神话

Jamstack并非新生事物。尽管该术语在2016年正式出现，但它所描述的技术和架构早已存在。最近，Jamstack受到了广泛关注，各大网站和出版物纷纷刊登相关报道，涌现出许多专注于Jamstack的活动、新闻通讯、播客等等。作为一名密切关注Jamstack的开发者，我什至观察到Twitter上的相关讨论显着增加，其中许多人都是初次接触这个概念。

热议的同时也伴随着批评。一些批评是合理的，我稍后会谈到其中一些，但另一些似乎是基于一些持续存在的关于Jamstack的常见误解，而这正是我首先要解决的问题。因此，让我们来看看我遇到的五个关于Jamstack的常见误解，并一一驳斥它们。与许多误解一样，它们通常基于一些真实情况，但却导致了错误的结论。

误解一：Jamstack只是静态网站的换名包装

JAMStack 99.9%是品牌营销，0.1%是实际内容。 ?? https://www.php.cn/link/33f976eca39cccf5a14627fc9f6cf1b9

— Nicole Sullivan – Black Lives Matter (@stubbornella) 2020年2月9日

是的，正如我之前所述，“Jamstack”这个术语可以说是对我们之前称为“静态网站”内容的重新包装。这并非旨在误导或销售尚未完全成型的产品——恰恰相反。 “静态网站”这个术语早已无法描述人们正在构建的内容。使用静态网站生成器(SSG) 构建的网站通常包含各种动态内容和功能。

静态网站主要被认为是博客和文档，其用户界面主要固定不变。交互的范围可能只是嵌入式评论和联系表单。另一方面，Jamstack网站则包含用户身份验证、动态内容、电子商务、用户生成内容等功能。

需要证据吗？一些使用Jamstack构建的知名公司和网站包括Smashing Magazine、Sphero、Postman、Prima、Impossible Foods和TriNet，仅举几例。

误解二：Jamstack网站脆弱

Jay Freestone，在《关于JAMStack的问题：你可能需要后端》一文中

阅读Smashing Magazine的依赖项列表就像服务端的node_modules一样，包括Algolia、GoCommerce、GoTrue、GoTell以及各种Netlify服务，仅举几例。了解哪些内容可以外包（以及何时外包）具有巨大的价值，但值得注意的是，在明显试图“回归基础”的过程中引入了复杂性。这更不用说依赖如此多的不同第三方服务所带来的潜在脆弱性了。

是的，为了实现将Jamstack与静态网站区分开来的动态功能，Jamstack项目通常依赖于各种服务，包括第一方或第三方服务。一些人认为，这使得Jamstack网站特别容易受到攻击，原因有两个。首先，他们说，如果任何一个部分发生故障，整个网站的功能就会崩溃。其次，你的基础设施变得过于依赖你所不拥有的工具和服务。

让我们来解决第一个论点。 Jamstack网站的大部分内容应该预先渲染。这意味着当用户访问网站时，页面及其大部分内容都将作为静态资源从CDN交付。这就是Jamstack获得大部分速度和安全性的原因。动态功能——如购物车、身份验证、用户生成内容和搜索——则依赖于无服务器函数和API的组合来工作。

广义地说，应用程序将调用充当后端的无服务器函数来连接到API。例如，如果我们的电子商务功能依赖于Stripe的API来工作，而Stripe宕机了，那么，是的，我们的电子商务功能将无法工作。但是，重要的是要注意，网站不会宕机。它可以通过告知用户问题来优雅地处理这个问题。依赖于Stripe API进行电子商务的服务器端渲染页面将面临相同的问题。假设服务器端渲染页面仍然异步调用后端代码进行支付，那么它与Jamstack版本相比，不会更脆弱或更不脆弱。另一方面，如果服务器端渲染实际上依赖于API调用，则用户可能会卡在等待响应或收到错误消息（任何使用网络的人都非常熟悉这种情况）。

至于第二个论点，很难衡量Jamstack Web应用程序与服务器端渲染应用程序对第三方的依赖程度。当今许多服务器端渲染应用程序仍然依赖于API来实现大量功能，因为这允许更快的开发，利用提供商的特定专业领域，可以卸载法律和其他合规性问题的责任等等。在这些情况下，服务器端渲染版本再次不会比Jamstack版本更依赖或更不依赖。诚然，如果你的应用程序主要依赖于内部或自制的解决方案，那么情况可能会有所不同。

误解三：编辑内容很困难

Kev Quirk，在《为什么我不使用静态网站生成器》一文中：

必须SSH进入Linux盒子，然后在Vim上编辑文章，这在移动写作方面似乎是一个非常高的入门门槛。无论你是否喜欢，当今世界都是移动优先的，因此移动写作应该很容易。

这个问题感觉像是过去静态网站的遗留问题。需要明确的是，你不需要SSH进入Linux盒子来编辑你的网站内容。有各种各样的无头CMS选项，从完全免费和开源到为大型企业提供内容的商业产品。它们提供的编辑功能可以与任何传统的CMS相媲美（我之前谈到过这一点）。关键是，没有理由手动编辑Markdown、YAML或JSON文件，即使是在你的博客副项目上也是如此。不确定如何连接所有这些部分？我们也有解决方案！

一个合理的批评是，无头CMS和构建过程可能会导致正在编辑的内容与网站上的更改之间脱节。在发布之前，或者没有一些复杂的构建预览过程，很难准确预览更改对实时网站的影响。生态系统正在解决这个问题。像Stackbit（我工作的地方）这样的公司正在构建使这个过程无缝的工具。

我们并不是唯一致力于解决这个问题的人。其他解决方案包括TinaCMS和Gatsby Preview。我认为我们即将在Jamstack之上运行像Wix这样的工具上实现所见即所得编辑的简单性。

误解四：Jamstack上的SEO很难

Kym Ellis，在《JAMstack对营销意味着什么》一文中：

放弃插件的概念，选择一个“只是HTML”的JAMstack网站，并不意味着你必须放弃功能，或者突然需要像前端开发人员一样学习编码来管理网站及其内容。

近年来，我没有看到这个问题经常出现，我认为这主要是静态网站时代的遗留批评，当时管理与SEO相关的元数据涉及手动编辑基于YAML的frontmatter。人们担心，正确地进行SEO会变得繁琐且难以维护，特别是如果你想为每个生成的唯一页面注入不同的元数据，或者创建像JSON-LD这样的结构化数据，这对于增强你的搜索列表至关重要。

Jamstack在内容管理方面的进步通常解决了维护SEO元数据的复杂性。此外，由于页面是预先渲染的，因此添加站点地图和JSON-LD相对简单，前提是所需的元数据存在。预渲染使创建搜索引擎（即谷歌）需要索引网站的资源变得容易，它们也与CDN结合，使实现提高网站排名的性能基准变得更容易。

基本上，Jamstack擅长“技术SEO”，同时也为内容编辑器提供了他们所需的关键词和其他元数据。要更全面地了解Jamstack和SEO，我强烈建议查看Bejamas的Jamstack SEO指南。

误解五：Jamstack需要大量的JavaScript框架

如果你试图向痴迷于最新框架的管理层销售普通的网站，那么一个宣传“JAMstack”优势的漂亮网站就非常有用。

– jdietrich，Hacker News

最近，Jamstack似乎已成为前端JavaScript框架的代名词。确实，许多最著名的解决方案都依赖于前端框架，包括Gatsby（React）、Next.js（React）、Nuxt（Vue）、VuePress（Vue）、Gridsome（Vue）和Scully（Angular）。这似乎是由对Jamstack中“J”的混淆加剧的。虽然它代表JavaScript，但这并不意味着所有Jamstack解决方案都是基于JavaScript的，也不意味着它们都需要npm或JavaScript框架。

事实上，许多最广泛使用的工具并非用JavaScript构建，特别是Hugo（Go）、Jekyll（Ruby）、Pelican（Python）和最近发布的Bridgetown（Ruby）。同时，像Eleventy这样的工具是用JavaScript构建的，但并不依赖于JavaScript框架。这些工具都没有阻止使用JavaScript框架，但它们并不需要它。

这里的重点并不是要抛弃JavaScript框架或使用它们的工具。这些都是很棒的工具，被许多开发人员成功使用。 JavaScript框架可以是非常强大的工具，能够简化一些非常复杂的任务。这里的重点仅仅是，认为需要JavaScript框架才能使用Jamstack的想法是错误的——Jamstack有460种风格！

我们可以改进的地方

就是这样吗？ Jamstack是一个理想的Web开发世界，在那里一切不仅完美，而且非常容易。不幸的是，不是。 Jamstack有很多合理的批评。

简单性

Sebastian De Deyne，在《在与JAMstack打交道后的想法（和疑问）》一文中：

以我的经验，JAMstack（JavaScript、API和标记）很棒，直到它不再很棒。当有一天我需要添加一些动态内容时——而这一天总是会到来——我开始挠头。

说实话：开始使用Jamstack并不容易。当然，使用静态网站生成器来构建博客或简单网站可能并不特别困难。但是，尝试构建一个具有任何动态功能的真实网站，事情很快就会变得复杂起来。

你通常会遇到许多完成任务的选项，这使得权衡利弊变得困难。 Jamstack最好的方面之一是它不是规定性的，但这可能会使它看起来难以接近，让人们留下这样的印象：它可能不适合复杂的任务。

绑定服务

当你真正开始构建那些动态功能时，你的网站最终可能会依赖于一系列服务和API。你可能会调用无头CMS获取内容，调用API进行支付交易的无服务器函数，像Algolia这样的搜索服务等等。将所有这些部分整合在一起可能是一项非常复杂的任务。再加上每个部分通常都有自己的仪表板和API/SDK更新，事情变得更加复杂。

这就是为什么我认为Stackbit这样的服务和RedwoodJS这样的工具很重要，因为它们将Jamstack网站背后的不同部分整合在一起，并使这些部分更容易构建和管理。

过度使用框架

在我看来，我们对现代前端开发中JavaScript框架的依赖最近受到了急需的质疑。正如Tim Kadlec最近的这篇文章所阐述的那样，存在权衡。正如我之前所说，你不需要JavaScript框架就可以在Jamstack中工作。

然而，这种印象的产生是因为许多Jamstack工具依赖于JavaScript框架，而且我们教授Jamstack的方式也主要集中在使用框架上。我理解这样做的原因——许多Jamstack开发人员对JavaScript框架很熟悉，而且不可能教授每种工具，所以你选择你喜欢的工具。尽管如此，我个人认为Jamstack的长期成功取决于它的灵活性，这（尽管我上面提到了简单性）意味着我们需要展示它提供的各种解决方案——无论是否使用JavaScript框架。

下一步去哪里

哇，你做到了！我知道我有很多话要说，也许比我开始写作时意识到的还要多，所以我不会用冗长的结论来烦你，除了要说，显然，我已经从一个非常相信Jamstack价值的人的角度来呈现这些误解，尽管它有缺陷！

如果你正在寻找一篇关于何时以及何时不选择Jamstack而不是服务器端渲染的好文章，请查看Chris Coyier最近的文章《静态与否？ 》。

以上是关于jamstack的5个神话的详细内容。更多信息请关注PHP中文网其他相关文章！