WordPress 和 Jamstack

Avatar of Chris Coyier
Chris Coyier

DigitalOcean 为您旅程的每个阶段提供云产品。 立即开始使用 200 美元的免费额度!

我最近在 Netlify 的虚拟 Jamstack Conf 上主持了一个小组讨论,参与者包括 Netlify 首席执行官 Matt Biilman 和 Automattic 创始人 Matt Mullenweg。 整件事被炒作成了——至少在某些人看来——一场“Jamstack 与 WordPress”的对抗。

我对这件事有很多自己的想法,并且认为我作为一名评论员比主持人更有用。 这是我目前在科技领域最喜欢的对话之一!所以请允许我写一篇博客

披露:Automattic 和 Netlify 都是本网站的活跃赞助商。 我有一些使用这两者的生产网站,老实说,我都是它们的粉丝,这是我将尝试阐述的一个总体观点。 我碰巧也正在 WordPress 网站上撰写和发布这篇文章。

历史

  1. Richard MacManus 发布了 “WordPress 联合创始人 Matt Mullenweg 不喜欢 JAMstack”,其中包含了他们之间电子邮件对话中的引述,Matt 说:“对于绝大多数采用 JAMstack 的人来说,这是一种倒退。”
  2. Matt Biilmann 发布了回复 “关于 Mullenweg 和 Jamstack——倒退还是未来?”,其中有一整个部分标题为“WordPress 时代的终结”。
  3. 人们一路纷纷发表意见。 Netlify 董事会成员 Ohad Eder-Pressman 写了一封公开信。 Sarah Gooding 总结了 WP Tavern 上的一些活动(该网站由 Matt Mullenweg 拥有)。 我也发表了评论
  4. Matt Mullenweg 澄清了他的言论,并添加了一些新的妙语。

这场辩论于 10 月 6 日在 Jamstack Conf Virtual 2020 上举行。 没有公开的视频(抱歉)。

架构

将 Jamstack 与 WordPress 进行比较有点奇怪。 可以进行比较的是,它们都是构建网站时可能采用的路径。 本文的大部分内容都会牢记这一点,并以此方式比较两者。 它们不能直接进行比较的原因是

  • Jamstack 是对一种架构理念的宽泛描述,该理念鼓励在 CDN 上使用静态文件,并使用 JavaScript 访问的服务器来满足任何动态需求。
  • WordPress 是一个基于 LAMP 架构的 CMS。

这些东西不是一回事。

如果我们暂时只关注架构,那么比较对象将是

  • 静态托管 + 服务
  • LAMP

静态 + 服务的一个例子是使用 Netlify 进行托管(它是静态的),并使用服务来执行任何需要执行的动态操作。 也许您使用 Netlify 自身的表单和身份验证功能以及 Hasura 进行数据存储。

在 LAMP 架构中,您有 MySQL 用于存储数据,因此您无需为此寻找外部服务。 您还可以使用 PHP。 因此,有了这些(以及开源软件),您就拥有了身份验证所需的一切。 这并不意味着您永远不会使用服务;只是由于您已经拥有服务器上的更多技术,因此您使用服务的频率较低。

Jamstack:以静态托管为中心,向外扩展到其他所有服务。


LAMP:以执行大量工作的服务器为中心,如有需要,可以扩展到少量服务。

Matt B. 将 LAMP 架构称为“单体”。 Matt M. 对此术语表示异议,并称之为“集成方法”。 我不是计算机科学家,但我可以理解这两种说法。 以下是维基百科的解释

[…] 单体应用程序 描述的是一个单层软件应用程序,其中用户界面和数据访问代码组合在一个程序中。

根据此定义,是的,WordPress 确实看起来像一个单体,但维基百科文章继续说道

[…] 单体应用程序描述的是一个设计时没有模块化的软件应用程序。

这样看来,WordPress 似乎不符合单体的定义。 WordPress 的钩子和插件架构是模块化的。 🤷‍♂️

听听这两位深入探讨其中的细微差别会很有趣,但软件就是软件。 自托管的 WordPress 网站运行在具有完整技术栈的服务器上。 尽可能多地利用该服务器是有道理的(即集成)。 在 Jamstack 方法中,服务器与您无关。 您需要执行的所有其他操作都分解成不同的服务(即未集成)。

WordPress 方法并不意味着您永远不会使用外部服务。 在这两种架构中,您都可能使用 Stripe 等电子商务 API。 您可能会使用 Cloudinary 等工具进行强大的媒体存储和服务。 甚至 WordPress 的 Jetpack 服务(我使用过并且很喜欢)也为自托管的 WordPress 网站带来了强大的功能,通过像第三方服务一样运行并将资产托管和搜索技术等内容从您自己的服务器转移到云服务器来实现。 两种架构都是技术的集合。

两种架构都不是“纸牌屋”,或者比另一种更容易倒塌。 所有网站都可能适用“其坚固程度取决于最薄弱的环节”的比喻。 如果 WordPress 插件发布了错误的版本或在上传时以某种方式被损坏,它可能会导致我的网站出现问题,直到我修复它。 如果我的无服务器数据库的 API 密钥失效,我的 Jamstack 网站可能会出现问题,直到我修复它。 如果 Stripe 宕机,那么在它恢复之前,我将无法在任何类型的网站上销售任何产品。

缺少分号可能会导致任何网站崩溃。

定价

WordPress.com 提供免费计划,您绝对可以在那里构建网站。(我有一些。)但是,除非您使用每月 25 美元的商业计划,否则您实际上无法获得开发者级别的访问权限。 自托管的 WordPress 本身是开源且免费的,但您不会找到免费启动自托管 WordPress 网站的地方。 起价很低,然后逐步增加。 您需要 LAMP 托管才能运行 WordPress。 以下是一些价格合理的托管计划的概览

一开始就需要花钱。

Jamstack 则更常见于免费开始,然后在不同的时间点产生费用。 由于 Jamstack 比较新,感觉市场仍在摸索阶段。

  • Vercel 是免费的,直到您需要团队成员或密码保护网站等功能。 单个密码保护网站每月 150 美元。 您可以将 基本身份验证 添加到任何使用 Apache 的服务器上,无需额外费用。
  • Netlify 非常相似,在更高层级的计划中解锁功能,并提供按站点计费的功能,如分析(每月 9 美元)和身份验证(5000 个活跃用户每月 99 美元)。
  • AWS Amplify 免费开始,但与 AWS 上的所有内容一样,您的使用情况在多个层面上都经过计量,例如构建分钟数、存储和带宽。 他们举了一个网络应用程序每天有 10,000 个活跃用户,每月更新两次的示例,每月费用为 65.98 美元。
  • Azure 静态 Web 应用 尚未发布定价,但几乎肯定会有免费层或免费使用额度或某种形式的免费使用。

所有这些都提醒我们,Netlify 并不是 Jamstack 游戏中唯一的参与者。 Jamstack 仅仅意味着静态托管加上服务。

您不能做出像 Jamstack 更便宜这样的笼统陈述。 这完全取决于网站的使用情况和需求。 对于高使用量和大量高级服务,Jamstack(就像无服务器一样)可能会变得非常昂贵。 Jamstack 表示其企业定价起价为每月 3000 美元,虽然您会获得身份验证、表单和媒体处理等功能,但您不会获得 CMS 或任何数据存储,这很可能导致您的费用大幅增加。

虽然此 WordPress 网站不是企业级的,但我可以告诉您,它需要一台大约每月 1000 美元的服务器,并且假设 Cloudflare 在其前面以帮助减少直接到主机的带宽,以及 Jetpack 处理媒体托管和搜索功能。 Mailchimp 发送我们的时事通讯。 Wufoo 为我们的表单提供支持。 我们还有付费插件,如 Advanced Custom Fields Pro 和一些 WooCommerce 插件。 这还不是全部。 总共可能需要几千美元每月。 这不是任何集成方法独有的,但有助于说明 WordPress 网站的成本也可能相当高。 他们没有公布价格(企业常用的策略),但 Automattic 自身的 WordPress VIP 托管服务 肯定起价为 4 位数,然后您才能开始添加第三方内容。

底线:这里没有发生定价方面的重大变化。

性能

80% 的网页性能问题都与前端有关。

这是一个真实的故事,但也建立在服务器的基础之上(占最初的20%)。如果服务器返回的第一个请求需要几秒钟,那么世界上最快的前端也感觉不到速度。如果你想要一个快速的网站,你必须确保第一个请求非常快。

第一个矩形是第一个服务器响应,第二个是整个前端。即使拥有快速的前端,也无法拯救你免受缓慢的后端的困扰。

你知道什么超级快吗?全球CDN提供静态文件。无论使用什么技术栈,这都是你希望在任何网站上实现的目标。虽然这是Jamstack(基于静态CDN的托管)的基础,但这并不意味着WordPress不能做到这一点。

你获取一个包含静态内容的index.html文件,将其放在Netlify上,它就会非常快。也许你的静态站点生成器创建了该文件(值得指出的是,它很可能从WordPress获取内容)。这种稳固的基础非常棒。

默认情况下,WordPress不会创建可在全局CDN上缓存的静态文件。WordPress从单个源响应请求,运行PHP,然后向数据库请求数据,在组装响应之前,最后,页面返回。这可能相当快,但远不如全局CDN上的静态文件稳定,并且更容易被请求压垮。

WordPress主机知道这一点,并且他们尝试在托管级别解决此问题。看看WP Engine的方法。无需你做任何事情,他们使用页面缓存,以便网站基本上可以返回静态资源,而无需运行PHP或访问数据库。他们还采用了各种其他缓存,包括与Cloudflare合作以进行最佳缓存。在我写这篇文章的时候,我的shoptalkshow.com网站真的宕机了。我写信给主机Flywheel询问情况。事实证明,当我进入那里打开一个暂存站点时,我错误地切换了一个开关,关闭了他们的缓存。该网站无法处理流量,直接崩溃了。重新打开缓存开关立即解决了问题。我当时没有在网站前面使用Cloudflare,但我应该使用。

Cloudflare是使WordPress速度更快的神奇秘方的一部分。只需将其放在你的自托管WordPress网站前面,就能在使其快速可靠方面发挥巨大作用。其中一个缺失的部分是HTML本身的出色缓存,他们本月才解决了这个问题,现在也可以缓存HTML了。这有点讽刺,缓存WordPress意味着将请求缓存为静态HTML和静态资源,并从全局CDN提供服务,从根本上说,这就是Jamstack最终要实现的目标。

Matt M.提到WordPress.com使用了在特定流量级别启动的全局CDN。我不确定是不是Cloudflare,但我不会怀疑。

在WordPress网站前面使用Cloudflare后,我看到的第一个响应数字与没有使用Cloudflare的Netlify网站相同(因为他们不建议在Netlify托管的网站前面使用Cloudflare)。那是两位数毫秒的数字,非常好。

由Flywheel托管并使用Cloudflare的WordPress网站css-tricks.com的第一个请求。非常快。
我的Jamstack网站conferences.css-tricks.com(由Netlify托管)的第一个请求。非常快。

在此基础上,任何关于性能的讨论都将变得特定于前端。无论后端的服务器、托管或CMS情况如何,前端的速度策略都是相同的。

安全

关于WordPress网站被黑客入侵的故事比Jamstack网站多得多。但说WordPress安全性较低是否公平?WordPress已经发展了二十多年的历史,并且在其上构建的网站数量比Jamstack多几个数量级。抛开安全性不谈,鉴于WordPress网站数量庞大,你自然会听到更多关于它的故事。

Matt M提到whitehouse.gov使用WordPress,这显然是一个需要最高安全级别的网站。这不是说WordPress本身是不安全的软件。而是你如何使用它。你的密码是否不安全?无论你使用什么平台,这都是不安全的。服务器本身是否通过文件权限或访问级别不安全?这并不完全是软件的错,但你可能因为软件而处于这种境地。你是否运行最新版本的WordPress?使用情况充其量是零散的,版本越旧,安全性就越低。很棘手。

思考安全途径可能更有意义。也就是说,在哪些方面可能被黑客入侵。如果你有一个位于静态托管上的静态文件,我认为可以肯定地说攻击途径相当少。但仍然有一些。

  • 你的托管帐户可能被黑客入侵
  • 你的Git仓库可能被黑客入侵
  • 你的Cloudflare帐户可能被黑客入侵
  • 你的域名可能被盗取(确实发生过

WordPress网站也同样如此,只是还存在其他攻击途径,例如

  • 服务器端代码:XSS、不良插件、远程执行等。
  • 数据库漏洞
  • 运行旧版、过时的WordPress
  • 登录系统位于网站本身,例如,坏人可以猛烈攻击/wp-login.php

我认为可以肯定地说,WordPress网站的攻击途径更多,但任何网站都有很多攻击途径。任何网站的托管帐户都是一个重要的途径。DNS链中的任何内容。任何具有登录信息的第三方服务。任何具有API密钥的内容。

个人经验:此网站使用WordPress,从未被黑客入侵过,但这并不是因为没有尝试。我确实觉得我需要比仅使用静态网站生成器构建的网站更多地考虑WordPress网站的安全问题。

扩展

扩展任何一种方法都需要花费金钱。此WordPress网站没有大规模扩展,但确实需要从入门级服务器需求进行一些不错的扩展。我通过Cloudflare提供所有流量,因此查看过去30天的数据可以告诉我,我每月提供5 TB的带宽。

在Netlify Business计划中(600 GB流量,价格为99美元,之后每增加100 GB需支付20美元),计算结果为979美元。还记得我之前说过这个网站大约需要一台每月花费约1000美元的服务器吗?我在运行这些数字之前写下了这些内容,所以我的预测非常接近(太棒了)。在这个网站的规模下,Jamstack与WordPress相比,几乎不相上下。所有主机都会对带宽收费,并设置上限以及超额收费。Amplify在每月15 GB的上限之后,每GB收取0.15美元。Flywheel(我的WordPress主机)根据每月访问者上限收费,超过上限后,每1000次访问收取1美元。

WordPress扩展的故事是

  • 使用能够处理扩展并且拥有自己成熟缓存策略的主机。
  • 为所有内容使用CDN(通常意味着在前面放置Cloudflare)。
  • 最终,你将为此付费。

Jamstack扩展的故事是

  • 主机和服务构建用于扩展。
  • 你无需过多考虑扩展方面,例如此服务能否处理此问题,或者我是否需要迁移?
  • 你需要更多地考虑扩展方面,例如每项服务的每个方面都将有你需要关注的定价。
  • 最终,你将为此付费。

我不得不调整WordPress托管,寻找符合网站当前需求的主机。迁移WordPress网站并非易事,但比迁移到其他CMS容易得多。例如,如果你在变得过于昂贵的无头CMS上构建了一个Jamstack网站,那么迁移的成本将比切换主机的工作量更大。

我喜欢Dave Rupert前几天(在Slack对话中)写的内容,关于比较两者之间的性能

Jamstack:使用任何工具构建你的东西,有插件来帮助你,并使用我们的工具将其部署到CDN,这样它就不会崩溃。

WordPress:使用我们的工具构建你的东西,有插件来帮助你,并且你必须使用某些主机才能使其不崩溃。

还有其他类型的“扩展”。我想到的是像用户数量这样的东西。这是各种服务用于定价层级的指标,这是一种可以理解的指标。但在WordPress中,这是免费的。你可以拥有尽可能多的用户,并拥有尽可能多的细致入微的权限。这仅仅是CMS,因此添加其他服务可能仍然会按人头收费。Vercel或Netlify按人头收费团队帐户。Contentful(一个流行的无头CMS)团队版每月起价为489美元。即使是GitHub的团队层级,如果你需要免费帐户无法提供的任何功能,也需要每用户支付4美元。

分离前端和后端

这是让大家对使用Jamstack构建感到兴奋的一大原因。如果我的网站的所有功能和内容都位于API后面,那么前端就可以自由地按照任何方式构建。

  • 想要构建一个全静态网站?好的,在构建过程中访问该API并执行此操作。
  • 想要使用React或Vue或其他任何东西构建一个客户端渲染的网站?没问题,在客户端访问API。
  • 想要拆分中间部分,预渲染一些,客户端渲染一些,服务器渲染一些?酷,这是一个API,你可以按照你想要的方式访问它。

这种灵活性在全新构建中很不错,但人们同样对理论上的未来灵活性感到兴奋。如果所有功能和内容都是API驱动的,那么你就完全分离了前端和后端,这意味着将来你可以更灵活地更改其中任何一个。

  • 只要你的 API 持续输出前端期望的内容,你就可以重新架构后端,而不会影响前端。
  • 只要你能获取到所需的数据,你就可以重新架构前端,而不会影响后端。

这种分离对于特定规模和体量的网站来说,感觉“未来可期”。我无法确切地说出这些规模的具体数值,但它们确实存在。

如果你曾经做过任何重大的网站重构,仅仅是为了适应一方或另一方,那么转向一个将后端和前端分离的系统,一定会感觉是一个明智之举。

一旦我们分离了,只要保持预期不变,后端 (B) 和前端 (F) 就可以独立发展。

可以分离一个 WordPress 网站(我们将在“两者兼用”部分讨论),但默认情况下,WordPress 非常注重集成式方法,前端是使用非常 WordPress 特定的 API,通过 PHP 中的主题构建的。完全没有分离。

开发者体验

Jamstack 在很大程度上优先考虑了开发者体验 (DX)。我听说有人称之为“局部最优”,这意味着 Jamstack 是围绕本地开发(以及本地开发者)体验设计的。

  • 你被期望在本地工作。 你在自己的舒适(本地、快速、自定义)开发环境中工作。
  • Git 是头等公民。 你推送至生产分支(例如 mastermain),然后你的构建流程运行,你的网站就会被部署。你甚至可以获得每个拉取请求的生产网站预览 URL,这是一个非常棒的功能。
  • 使用任何你喜欢的工具。 你想在 Hugo 中预构建一个网站?尽管去做。你在学校学习了 create-react-app?那就用它。想尝试一下当下的酷炫新框架?尽管来吧。你有很大的自由度来构建你想要的任何东西,利用你可以运行构建并部署你仓库中任何你想要的文件夹这一事实。
  • 不必做的事情也很重要。 你不必处理 HTTPS,不必处理缓存,不必担心文件权限,不必配置 CDN。即使是高级开发人员也喜欢少做一些事情。

这并不是说 WordPress 没有考虑开发者体验(例如,他们有一个 CLI,它可以做一些有用的事情,比如 创建区块脚手架),但在我看来,DX 感觉不像项目的核心。

  • 在本地运行 WordPress 很棘手,需要你以某种方式运行 (X)AMP 堆栈,这涉及到臭名昭著的、难以捉摸的第三方软件。感谢 Local by Flywheel。有一些 指导,但感觉这并不是优先事项。
  • 什么应该放在 Git 中? 到今天为止,我仍然不太清楚,但我基本上已经决定将整个 /wp-content 文件夹都放进去。对我来说,没有指导或明显的最佳实践,这感觉很奇怪。
  • 部署完全需要你自己来做。 即使是 WordPress 特定的主机,在这方面也没有真正做好。基本上就是:这是你的 SFTP 凭据
  • 即使你设置了一个不错的本地开发和部署管道(我对我的很满意),这并不能真正帮助处理数据库的迁移,所以你在这方面也需要自己解决。

这些都是可以解决的问题,WordPress 社区非常庞大,你会找到很多相关信息,但我认为可以公平地说,WordPress 并没有将 DX 作为核心。即使经过了这么多年,它仍然有点像“蛮荒西部”。

事实上,我发现,由于对健康的本地开发环境的鼓励被边缘化,很多人都根本没有本地开发环境。这是我个人的观察,但现在已经有两年时间,我发现自己参与了其他人的网站,这些网站完全只在生产环境中运行。如果它们是非常简单的网站,并且基本上使用默认行为,那倒还好,但这些网站却并非如此。它们非常复杂(比这个网站复杂得多),涉及公共用户登录、付费会员资格和权限、页面构建器、自定义短代码、自定义 CSS,以及大量活动部件。这让我不寒而栗。我不想碰任何东西。他们正在实时编辑 PHP 以使事情正常工作——牛仔编程,人们开玩笑地称之为。一个语法错误,网站就挂了,甚至你正在查看的页面也可能挂了。

WordPress 驱动了网络如此庞大的部分,而没有特别好的 DX,这非常有趣。没有 DX 就没有 Jamstack。这是一件完全面向开发者的事件。对于 WordPress 来说,大多数网站可能根本没有开发者。它被安装(或者在 WordPress.com 的情况下被激活),然后网站所有者从那里开始。网站所有者就像一个开发者,因为他们拥有很大的权力,但也许根本不会编写任何代码。

就此而言,我想说 WordPress 更加关注 UX 而不是 DX,这是这一切中非常重要的一部分……

CMS 和最终用户 UX

WordPress 是一个非常棒的 CMS。即使不喜欢它,也有很多人喜欢它,数据本身就说明了一切。当你决定使用 WordPress 构建一个网站时,你获得的是构建几乎任何你想要的网站的能力。使用 WordPress,你不太可能遇到那种哎呀,把自己逼到死胡同里了的情况。

这是一件大事。Jenn 指出了这一点,她指出使用 WordPress 的人比开发者的需求更重要。

WordPress 可以做非常多的事情

  • 博客(或成为 任何类型 的内容驱动型 CMS 风格的网站)…
    • 具有内容预览功能,这在 Jamstack 上是可能但很棘手的
  • 处理用户/权限…
    • 在管理员/CMS 层面,以及
    • 在面向用户层面(例如 论坛订阅社交 等)
  • 电子商务
  • 处理表单
  • 处理插件,无穷无尽

Jamstack 也绝对可以做到所有这些事情,但现在是 Jamstack 处于“蛮荒西部”的境地。当你查看有关如何存储数据的教程时,它们通常会涉及解释如何为云数据库编写单独的 CRUD 函数。那是非常底层的操作,可以非常强大,但它与点击几个按钮相去甚远,而这正是 WordPress 在很多时候给人的感觉。

我敢打赌,我可能可以用 Stripe API 拼凑出一个基本的 Jamstack 电子商务设置,这非常酷。但随后当我需要开始考虑库存管理、运送区域、产品变体以及谁知道电子商务领域还有什么复杂的东西时,我就会开始感到紧张,这让我希望有一个超级强大的东西可以帮我搞定所有事情。

有时,我们开发者只是为自己构建网站(我做了很多这样的事情),但我想说,开发者大多是在为其他人构建网站。所以最重要的问题是:我构建的东西是否能为我为之构建的人赋能?

无论使用什么,你都可以实现良好的网站管理体验,但 WordPress 已经证明,它在这一领域提供了出色的表现,而无需在自定义开发方面投入太多。

不过,Jamstack 有一些技巧,我希望我能在 WordPress 上实现。对我来说,其中一个很重要的技巧是:用户提交的内容和更新。我现在真的有三个网站受益于这一点。一个关于 会议 的网站,一个关于 无服务器 的网站,以及一个即将推出的关于 编码字体 的网站。WordPress 完全可以在这三个网站上做得很好。但是,我真正想要的是让人们能够以一种让我能够像这样更新和提交内容的方式:是的,看起来不错,合并。 通过使用 Jamstack 方法,内容位于公共 GitHub 仓库中,任何人都可以参与。

我认为这非常棒。它甚至不一定要求公众中的某个人了解或理解 Git 或 GitHub,因为 Netlify CMS 有一个 开放创作 的概念,它将整个贡献体验保留在浏览器中,并提供用于编辑的 UI。

两者兼用

这是一个我经常看到被提到的重要问题。甚至 Netlify 本身也表示 “没有对比”。

事情是这样的

  • “Jam”中的“A”代表 API。在构建时或客户端使用 API 来构建你的网站。
  • WordPress 网站默认情况下具有 REST API(也可以有 GraphQL API)。
  • 因此,在你的 Jamstack 网站上访问该 API 以获取 CMS 数据。

是的,完全可以。这行得通,而且 人们确实在这样做。我认为这很酷。

但是…

  • 除了你的 Jamstack 网站之外,还在某个地方运行 WordPress 网站意味着……你除了 Jamstack 网站之外,还在运行 WordPress 网站。这会带来成本和技术债务。

  • 你经常无法充分利用 WordPress 的价值。可能你只需要调用 API 获取数据,但这与构建 WordPress 主题相比,是一种**完全不同的**网站构建方法。你无法获得 WordPress 的其他任何价值。我想到的是这样的情况:你找到一个很酷的插件,它为你的网站添加了一个花哨的 Gutenberg 块。这在 WordPress 网站上“可以正常工作”,但它可能具有一些特殊的前端行为,如果你只是从 API 中提取 HTML,这些行为将无法正常工作。它可能会加载一些额外的脚本和样式,你需要自己想办法将它们整合到你的前端托管位置,并且需要自己维护更新。

以下是一些都采用了独特“两种方式结合使用”方法的参与者。

  • Frontity:一个用于 WordPress 的 React 框架。除了你的 WordPress 网站之外,你还可以使用它与 Node 服务器一起运行。Node 服务器将 React 渲染成 HTML,因此你可以为所有页面获得服务器端渲染,但你仍在构建一个SPA
  • WP2Static:一个 WordPress 插件,它可以构建你的网站的静态版本,并在进行更改时自动部署。
  • Strattic:他们为你托管动态 WordPress 网站(他们称之为“暂存”),你可以在那里正常使用 WordPress。然后你可以选择部署,他们还会为你托管网站的静态版本。
  • Shifter:Shifter 为你托管 WordPress 网站。你有两种选择:1) 无头运行(因此你只是调用 API,REST 或 GraphQL 获取数据)或 2) 静态运行(因此,当你将所有内容都放在 WordPress 中想要的位置时,你将其部署,这将创建你的网站的静态版本,他们也会托管它,或者你可以将其推送到其他地方,例如 Netlify)。

还有很多其他方法可以整合两者。这是我们自己的 Geoff 和 Sarah关于将 WordPress 和 Jamstack 结合使用的文章,他们使用 Vue/Nuxt 和 REST API 并托管在 Netlify 上。

不使用两者

以防万一这一点不清楚,构建网站的方法绝对有很多。如果你正在构建一个 Ruby on Rails 网站,那既不是 Jamstack 也不是 WordPress。你可以认为它更像一个 WordPress 网站,因为它需要一个服务器,并且你将使用该服务器来完成尽可能多的工作。你也可以认为它更像 Jamstack,因为即使它不是静态托管,它也鼓励使用 API 和拼凑服务。

网络是一个很大的地方,伙计们,这不是一个零和游戏。我完全预计 WordPress 将继续发展并且Jamstack 将继续发展,因为网络本身正在发展。即使我们只考虑市场份额的百分比,我仍然认为两者都会增长,将其他任何事物推向更小的份额。

选择

我甚至不想在这里讨论。不是因为我避免偏袒,而是因为没有必要。我没有看到开发人员在那里咬着指甲,试图在构建网站的 WordPress 或 Jamstack 方法之间做出决定。我们已经到了技术足够了解的程度,这个过程是这样的

  1. 穿上成人裤子
  2. 评估需求和结果
  3. 选择技术