我最近在 Netlify 的虚拟 Jamstack Conf 上主持了一个小组讨论,参与者包括 Netlify 首席执行官 Matt Biilman 和 Automattic 创始人 Matt Mullenweg。 整件事被炒作成了——至少在某些人看来——一场“Jamstack 与 WordPress”的对抗。
我对这件事有很多自己的想法,并且认为我作为一名评论员比主持人更有用。 这是我目前在科技领域最喜欢的对话之一!所以请允许我写一篇博客。
披露:Automattic 和 Netlify 都是本网站的活跃赞助商。 我有一些使用这两者的生产网站,老实说,我都是它们的粉丝,这是我将尝试阐述的一个总体观点。 我碰巧也正在 WordPress 网站上撰写和发布这篇文章。
历史
- Richard MacManus 发布了 “WordPress 联合创始人 Matt Mullenweg 不喜欢 JAMstack”,其中包含了他们之间电子邮件对话中的引述,Matt 说:“对于绝大多数采用 JAMstack 的人来说,这是一种倒退。”
- Matt Biilmann 发布了回复 “关于 Mullenweg 和 Jamstack——倒退还是未来?”,其中有一整个部分标题为“WordPress 时代的终结”。
- 人们一路纷纷发表意见。 Netlify 董事会成员 Ohad Eder-Pressman 写了一封公开信。 Sarah Gooding 总结了 WP Tavern 上的一些活动(该网站由 Matt Mullenweg 拥有)。 我也发表了评论。
- Matt Mullenweg 澄清了他的言论,并添加了一些新的妙语。
这场辩论于 10 月 6 日在 Jamstack Conf Virtual 2020 上举行。 没有公开的视频(抱歉)。
架构
将 Jamstack 与 WordPress 进行比较有点奇怪。 可以进行比较的是,它们都是构建网站时可能采用的路径。 本文的大部分内容都会牢记这一点,并以此方式比较两者。 它们不能直接进行比较的原因是
- Jamstack 是对一种架构理念的宽泛描述,该理念鼓励在 CDN 上使用静态文件,并使用 JavaScript 访问的服务器来满足任何动态需求。
- WordPress 是一个基于 LAMP 架构的 CMS。
这些东西不是一回事。
如果我们暂时只关注架构,那么比较对象将是
- 静态托管 + 服务
- LAMP
静态 + 服务的一个例子是使用 Netlify 进行托管(它是静态的),并使用服务来执行任何需要执行的动态操作。 也许您使用 Netlify 自身的表单和身份验证功能以及 Hasura 进行数据存储。
在 LAMP 架构中,您有 MySQL 用于存储数据,因此您无需为此寻找外部服务。 您还可以使用 PHP。 因此,有了这些(以及开源软件),您就拥有了身份验证所需的一切。 这并不意味着您永远不会使用服务;只是由于您已经拥有服务器上的更多技术,因此您使用服务的频率较低。
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。 以下是一些价格合理的托管计划的概览
- Bluehost 的“共享”计划 起价为每月 3.95 美元。
- Flywheel 上的最低计划 为每月 14 美元。(此网站使用 Flywheel 的高级计划。)
- Media Temple 提供 WordPress 专用托管,起价为每月 20 美元。(此网站很长时间都使用 Media Temple 的高层级计划。)
- Automattic 的 Pressable 服务提供起价为每月 25 美元的计划。
一开始就需要花钱。
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)。那是两位数毫秒的数字,非常好。


在此基础上,任何关于性能的讨论都将变得特定于前端。无论后端的服务器、托管或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 持续输出前端期望的内容,你就可以重新架构后端,而不会影响前端。
- 只要你能获取到所需的数据,你就可以重新架构前端,而不会影响后端。
这种分离对于特定规模和体量的网站来说,感觉“未来可期”。我无法确切地说出这些规模的具体数值,但它们确实存在。
如果你曾经做过任何重大的网站重构,仅仅是为了适应一方或另一方,那么转向一个将后端和前端分离的系统,一定会感觉是一个明智之举。
你可以分离一个 WordPress 网站(我们将在“两者兼用”部分讨论),但默认情况下,WordPress 非常注重集成式方法,前端是使用非常 WordPress 特定的 API,通过 PHP 中的主题构建的。完全没有分离。
开发者体验
Jamstack 在很大程度上优先考虑了开发者体验 (DX)。我听说有人称之为“局部最优”,这意味着 Jamstack 是围绕本地开发(以及本地开发者)体验设计的。
- 你被期望在本地工作。 你在自己的舒适(本地、快速、自定义)开发环境中工作。
- Git 是头等公民。 你推送至生产分支(例如
master
或main
),然后你的构建流程运行,你的网站就会被部署。你甚至可以获得每个拉取请求的生产网站预览 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 可以做非常多的事情
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 方法之间做出决定。我们已经到了技术足够了解的程度,这个过程是这样的
- 穿上成人裤子
- 评估需求和结果
- 选择技术
关于:同时使用。我认为WPGraphQL应该在这里提及。毕竟,它现在是 Gatsby Org 的一部分。
这是一篇很棒的文章。我发现自己身处这两个世界,我喜欢创建自定义页面类型、使用分类法和 acf 块增强 Gutenberg 的灵活性。部分内容我使用 wp json API 获取,用 vue 处理,其余部分使用 wp rocket 静态构建。CDN 负责其余工作。每月不到 100 欧元,我就能获得一个不错的构建,可以处理几乎无限数量的用户。
我一直期待着这篇文章。我从事前端开发已经超过十年了。大部分时间都在使用 LAMP。但我要诚实地说,我还没有能够完全切换,因为有很多变量。在过去的两年里,我一直在玩 React、Vue 和 Jamstack,我只能说我迫不及待地想告别 WordPress。我一直暗地里讨厌 WordPress 的一切,我的直觉告诉我 Jamstack 是未来。设计、开发和数据完全分离。我不必将我的所有数据都包装到堆栈本身中。现在我可以完全分离客户的数据,无论何时我们决定将网站升级到新的设计或开发,我们都可以保留这些数据。我喜欢将数据直接拉到静态文件上的想法。这就像网络应该成为的样子!!将我们带回早期,但使用现代技术。能够创建多个可重用部分的组件。将所有数据放到任何你想要的地方,并将其拉到页面上。不要误解我的意思,WordPress 非常强大,并且一直是一个很棒的工具。但在转向 Jamstack 时,人们在讨论这些问题时隐藏的一个问题是,Jamstack 确实需要大量的打包和工具才能预览和发布到生产环境,这有时会违背初衷。但我认为 Jamstack 的理念是只编写一次代码,只编写功能代码,并将运行网站的数据放在其他地方。因此,从本质上讲,你不会不断更新核心文件。我对 Jamstack 非常兴奋。
这是其中最令人兴奋的部分……
“Jamstack 也绝对可以做所有这些事情,但现在是 Jamstack 处于狂野西部时期。”
我当然正在寻找更多参与并为社区做出贡献的方法。感谢这篇文章。
我看到了这场辩论,这是一个非常合理的总结。在职业生涯中,我有很多东西都依赖于 JAMStack 的成功,并且围绕它开发了相当数量的特定领域技能,而没有涉足另一个阵营(PHP——那是什么?),但我尽量避免对此产生极化。
这种公正的分析是对围绕 Jamstack 与 WP 的持续争论的急需补充。我发现围绕“我的堆栈比你的堆栈更好”的对话充其量是虚伪的,因为它过于简单化且缺乏透明度。正如你所阐述的那样,两者在所有层面都各有优缺点,而且它们甚至可以很好地协同工作:Jamstack 可以使用 WP 作为后端,而 WP 可以作为“Jamstack”部署,即通过 CDN 提供的静态文件。
另外,感谢你提到 Strattic。自从我开始从事网页开发以来,我一直是它的忠实粉丝 :)
相当公平的比较和解释。通过阅读这篇文章,我重新学习了一些基础知识。应该有一段关于 Mats 的讨论的视频,真是可惜。
WordPress 已经存在一段时间了,所以人们有时间了解其局限性。Jamstack 是一种较新的方法,所以我感觉更容易相信炒作并忽略权衡取舍……直到你遇到它们。
所以我认为 Matt 的抵制在这方面是健康的,它有助于平衡一些事情!
我很幸运能够参加 Matt Mullenweg 和 Matt Biilman 之间的辩论。很遗憾它没有公开发布。我绝对是 Jamstack 的支持者,但这场讨论正在升温,我认为这对整个 Web 开发人员社区来说是一件好事。
关于电子商务,我想对此发表评论
你如此紧张的原因是 Stripe “仅仅”是一个支付 API,而不是一个电子商务 API。收款只是你在网上销售时需要管理的众多方面之一。如果你希望拥有一个超级强大的工具来完成所有工作,我非常想说你得到了它,Chris。但我同时是 Commerce Layer 的 CEO,我不想显得太“推销” :)
感谢你,Chris,提供了一个有见地且重要的是客观冷静的比较。
老式的 WordPress 开发人员最近可能会感觉有点被贬低——很高兴听到我们所做的事情仍然具有相关性和价值。
感谢你的这篇有趣的文章。
可以说两种方法都可以使用,但必须评估哪种方法最适合特定的项目。
我使用 WordPress 很长时间了,我仍然喜欢它,但对于小型项目来说,它的维护很痛苦,而且托管费用很高。
如果你需要一个 4/10 页的网站(首页 - 关于 - 产品/服务 - 联系方式,甚至一个小博客),在我看来使用 WordPress 简直是杀鸡用牛刀。使用 Jamstack 解决方案,你可以节省很多钱,并且减少检查更新的任务以避免网站被黑客入侵(当然托管服务也可能被黑客入侵,但在两种情况下,你所能做的只有选择一个值得信赖且专注于安全性的服务)。
这是一篇很棒的博文,但我认为它没有做到尽善尽美,因为在某些边缘情况下,事情可能会更进一步。例如,如果静态托管在 IPFS 上,并且每次成功构建时只需更新简单的 DNSLink 指向 Cloudflare 的免费 IPFS 服务,那么 JAMstack 的成本效益可以变得更低。因此,下一代 JAMstack 的成本将取决于构建文件的大小,而不是为带宽支付托管账单。这是我在关于 JAMstack 与 WordPress(或任何其他技术栈)的讨论中从未听过的,但你现在就可以去做。
JAMstack 的批评者也夸大了第三方服务的成本。任何 JAMstack 网站都可以不使用数千美元的服务并且仍然运行良好,即使它们确实需要这些服务,它们也可以编写自己的微服务或使用开源替代方案(Algolia 有开源替代方案Meiliseach)。我认为,第三方 API 服务的开源替代方案将在未来随着 JAMstack 生态系统的增长而发展。让我们拭目以待。
从长远来看,我认为现在下结论说 JAMstack 比其他任何技术栈都更好还为时过早。不仅因为“你可以将这个技术栈变成 JAMstack 或者你可以同时使用两者”,而且我认为我们仍处于摸索 JAMstack 真正含义的阶段,具有讽刺意味的是,我们没有将新兴的 Web 3.0 去中心化网络趋势考虑在内——我们将看到 JAMstack 如何真正闪耀的趋势。
我也要插话表示感谢,这是一篇写得很好且没有夸大其词的文章。
我可能要补充一点,这篇文章似乎主要从开发人员的角度出发,并没有真正涉及内容创建者,即作者。许多人想要使用 WordPress,因为它易于创建博客/网站。人们如何在 Jamstack 网站上实际创建内容?
感谢这篇文章并分享了关于成本估算的这些数据。非常有参考价值的比较。
我们通过 WP2Static 使用这两种方法。因为我们仍然享受 WordPress 在内容创建和展示方面的流程。它并不完美,但我们发现 wp2static 对于在共享主机预算下拥有安全且高性能的网站来说是一个非常经济高效的解决方案。
Chris,你对整个情况的看法很好。我和你一样。我同时使用 WordPress 和 Jamstack(以及其他技术,例如 Next.js)。无论如何,我无法离开 WordPress。它非常有用。我已经多次将其扩展到数百万用户,而费用却微不足道。
…但是,是的,总是有个但是——在使用 WordPress 14 年(作为用户和贡献代码的核心开发者之一)之后——我开始与 WordPress 疏远,因为 WordPress 在开发者工具方面缺乏投入。
WordPress 在开发者体验方面可以得到很多帮助。尤其是在尝试使用 PHP 和 JavaScript(React)进行编码时。开发者工具可以大有裨益。并且在为社区构建多个 开发 工具后,我发现前来帮忙的开发者越来越少(大多数人要求免费支持),我面临着来自不理解开发者体验对 WordPress 社区价值的人的批评和辱骂。
另一方面,在 Next.js、Vercel、Jamstack 等框架中,我看到了对开发者体验的极大关注——如果我构建一个工具来提供帮助,人们就会贡献,更多开发者会对这类事情感到兴奋,因此他们中的更多人正在让 Jamstack 变得更好。
总之,这不是一场“对比”的辩论——因为现在我正在考虑将我用 WordPress、k8s、Go 语言微服务构建的自定义课程平台重写为 Next.js、Vercel 和 WordPress(作为无头 API 后端 + 管理仪表盘,因为我从中获得了如此多的好处)。
好吧,让我们看看会发生什么。
“我想说 WordPress 比 DX 更关注 UX,这是这一切的重要组成部分……”
对我来说,这是切换到 Jamstack 的主要问题。WordPress 为你提供了如此庞大的主题库可供选择,无论是免费的还是付费的,当你设计一个网站时。使用 Jamstack 方法,你可以使用一些设计工具,例如 Bootstrap 或 Materialize,但设计/UX 仍然比使用 WordPress 耗费更多时间。
嘿 @Chris Coyier,你能写一篇关于“Joomla 和 Jamstack”的文章吗?
在构建 Jamstack 网站时,我担心的一件事是我选择的服务的稳定性和持久性。例如,如果我需要一个数据库,我担心我使用的提供商是否会更改其 API、更改其定价或被另一家公司收购并停止使用。
而在 WordPress 世界中,我知道我拥有集成的数据库,并且可以使用可预测的方法存储和检索数据,这些数据在未来几年内不会发生重大变化。
使用服务的另一个方面是您必须学习它们,并且所需的技能和知识不一定具有可移植性。(参见 Marco Arment 关于网络托管的这篇文章:https://marco.org/2014/03/27/web-hosting-for-app-developers)。
这些只是我个人的担忧,我可能是杞人忧天了。