JAMstack 基础知识：什么、什么以及如何

我们喜欢在网络上突破界限，所以我们决定尝试一些新的东西。 您可能听说过 JAMstack — 基于 JavaScript、API 和标记的新 Web 堆栈 — 但它对您的工作流程意味着什么？它什么时候对您的项目有意义？

作为 Smashing Membership 的一部分，我们每周都会举办一系列现场网络研讨会Smashing TV 。 不虚张声势——只是实用的、可操作的网络研讨会，由业内备受尊敬的从业者主持，并提供现场问答。 事实上，Smashing 的电视节目表看起来已经很密集了，而且它对 Smashing 会员以及录音都是免费的——显然。

我们恳请 Phil Hawksworth 举办一次网络研讨会，解释 JAMStack 的实际含义和意义，以及它如何影响工具和前端架构。 时长一小时的网络研讨会现在也可用。 我们非常高兴地欢迎 Phil 共同主持我们即将举行的 SmashingConf Toronto（6 月 25 日至 26 日）并运行 JAMStack_conf London，我们也在今年 7 月 9 日至 10 日共同组织。 所以，让我们开始吧！

Phil Hawksworth：太好了，好吧，那么让我们开始吧。 顺便打个招呼，我的意思是我已经打过招呼了，斯科特给了我一个很好的介绍。 但是，是的，我目前在 Netlify 工作，我在那里的开发人员体验团队工作。 我们希望有足够的时间进行问答，但是，正如斯科特所说，如果你没有机会在那里提问，或者你宁愿，你可以直接在 Twitter 上向我发送消息，所以我的 Twitter 句柄是我的名字，我是 Phil Hawksworth，所以任何时候你都可以在 Twitter 上向我提问有关 JAMstack 或任何内容的问题。

菲尔霍克斯沃斯：但我想从今天开始，稍微回顾一下这句话，这确实引起了我非常非常强烈的共鸣。 这是出色的 Aaron Schwartz 的一句话，他当然为知识共享和开放网络做出了巨大贡献，他早在 2002 年就在博客上写了这篇文章，他说：“我关心不必保持暴躁AOL 服务器、Postgres 和 Oracle 安装。” AOL 服务器，我不得不抬头提醒自己当时是一个开源的 Web 服务器。

菲尔霍克斯沃斯：但这对我来说真的很强烈。 我也不想维护基础设施来保持博客的活力，这就是他所说的。 这是在他自己的博客上的这篇博客文章，标题为“烘烤，不要油炸”。 他选择了一个最近建立 CMS 的人开始使用的术语，并且他将这个关于烘焙的术语（烘焙，不要油炸）普及了； 他所说的是预渲染而不是按需渲染，因此提前烘焙内容，而不是在人们来请求时按需煎炸 - 将事情从请求时间转移到构建时间。

Phil Hawksworth：当我们谈论预渲染和渲染时，我们的意思是我们正在谈论生成标记。 有时谈论服务器渲染或同构渲染或许多此类流行术语时，我会感到有点不自在； 几年前，我在阿姆斯特丹的 Frontiers Conference 会议上被叫到，当时我正在谈论在服务器上渲染，有人对我说，“你的意思是生成 HTML？ 只是输出 HTML 的东西？” 当然，这就是我的意思。

Phil Hawksworth：但所有这些都对简化堆栈大有帮助。 当我们考虑我们为网站提供服务的堆栈时； 我一直在尝试简化事情，我非常热衷于尝试简化堆栈。 这就是所谓的“JAMstack”的核心，我想试着解释一下。 JAMstack 中的“JAM”代表 JavaScript、API 和标记。 但这还不足以真正帮助我们理解它的含义——这到底是什么意思？

Phil Hawksworth：嗯，我想在接下来的半小时左右尝试做的是，我想扩展这个定义，并更多地描述 JAMstack 是什么。 我想谈谈 JAMstack 的影响和影响，并且，你知道，想想它能给我们带来什么，为什么我们会选择它。 在此过程中，我将尝试提及一些有用的工具和服务，希望我会总结一些您可能想要深入研究的资源，并可能会提及一些让您了解的第一步进行中。

Phil Hawksworth：所以，这就是接下来半小时的计划。 但是，我想回到简化堆栈的概念，因为希望以后加入或观看此视频的人，也许您对 JAMstack 有一个概念，或者也许这是一个全新的术语，你只是好奇。 但是，最终，已经有很多堆栈了。 您可以通过多种方式交付网站。 感觉就像我们已经构建不同类型的基础架构已经很长时间了，无论是 LAMP 堆栈还是 MAMP 堆栈，还是——我不知道——MEAN 堆栈。 这里的屏幕上漂浮着一堆。 它们有很多很多。

Phil Hawksworth：那么，我们到底为什么需要另一个呢？ 好吧，正如我所提到的，JAMstack 是 JavaScript/API/Markup，但如果我们尝试更具描述性，JAMstack 旨在成为一种现代架构，以帮助使用 JavaScript/ 创建快速、安全的网站和动态应用程序/ API 和预渲染标记，在没有 Web 服务器的情况下提供服务，最后一点是让它与众不同的东西，也许，让它变得更有趣和不寻常。

Phil Hawksworth：这种在没有 Web 服务器的情况下提供服务的概念，听起来既神奇又荒谬，希望我们能弄清楚到底是什么。 但是为了尝试对此有所了解并更详细地描述它，有时将其与我们可能认为的传统堆栈或在网络上提供服务的传统方式进行比较是有用的。 所以，让我们做一秒钟。 也许，让我们来看看一个请求在传统堆栈中得到服务时的样子。

Phil Hawksworth：因此，在这种情况下，我们让某人打开 Web 浏览器并请求查看页面。 也许该请求会命中 CDN，但更可能的是，它会命中我们托管的其他一些基础设施——作为拥有该站点的人。 也许我们试图确保它能够在大量负载下扩展，因为我们显然想要一个非常受欢迎和成功的场景。 因此，也许我们有一个负载均衡器，其中包含一些逻辑，它将为我们提供、配置和部署到的多个 Web 服务器之一提供该请求。 可能有许多这样的服务器。

Phil Hawksworth：这些服务器会执行一些逻辑，说：“好的，这是我们的模板，我们需要用一些数据填充它。” 我们可能会从许多数据库服务器中的一个获取数据，这些服务器将执行一些逻辑来查找一些数据，将其返回到 Web 服务器，创建一个视图，然后我们通过负载平衡器传回该视图。 也许，在此过程中，调用 CDN，在 CDN 中存储一些资产，我应该澄清一下，CDN 是一个内容交付网络，因此分布在 Internet 周围的机器网络试图尽可能接近地获取请求服务给用户并添加一些东西，比如缓存。

Phil Hawksworth：因此，我们可能会在其中存储一些资产，并最终将视图返回到浏览器中，返回到用户的眼球中，然后用户可以体验我们构建的网站。 因此，显然，这要么是对我们如何在传统堆栈中服务请求的过度简化，要么是非常笼统的看法。 如果我们将其与 JAMstack 进行比较，后者以稍微不同的方式为事物提供服务，这就是它的外观。

Phil Hawksworth：所以，同样的情况，我们从网络浏览器开始。 我们正在请求查看该页面，并且该页面已经在 CDN 中。 它从那里静态地服务，所以它被返回给用户，进入浏览器，我们就完成了。 因此，显然，这是一个非常简化的视图，但您可以立即开始看到这里在复杂性方面的差异。 就我们需要管理代码的地方而言，深度编码，所有这些不同的事情。 所以，对我来说，JAMstack 的核心属性之一是它意味着您正在构建一个能够直接从 CDN 甚至是静态文件服务器提供服务的站点。 CDN 是我们可能想要用来处理负载的东西，但最终，这可以直接从任何类型的静态文件服务器、静态托管基础设施中提供服务。

Phil Hawksworth： JAMstack 提供了一个降低复杂性的机会。 在接下来的半小时内，只需比较我们将多次返回的图表的这两个部分，您就会发现这是降低复杂性和降低风险的机会。 因此，这意味着我们可以开始享受为静态资产提供服务的一些好处，稍后我将讨论这些好处。 但是您可能会看着这个并想，“嗯，很好，但这不只是静态网站的新名称吗？” 当我说“我们将静态地为事物服务”时，这对我来说是合理的。

菲尔霍克斯沃斯：但我想回到那个。 我想多谈一点，但首先，我想谈谈堆栈的概念，到底什么是堆栈？ 我认为堆栈是技术层，它提供您的网站或应用程序。 而且我们不是在谈论构建管道或开发过程，而是我们为站点提供服务的方式肯定会对我们的开发方式和部署方式等产生重大影响。

Phil Hawksworth：但是在这里，我们谈论的是技术堆栈，技术层，它们实际上将您的网站和应用程序交付给用户。 所以，让我们再做一个小比较。 让我们先谈谈 LAMP 堆栈。

Phil Hawksworth：您可能还记得，LAMP 堆栈是由一个 apache Web 服务器组成的，用于执行 HCP 路由和静态资产服务等工作。 PHP，用于一些预处理，非常漂亮的超文本处理； 应用逻辑，也许为模板构建视图以及你有什么。 并且可以通过我的 NISQL 访问您的数据，然后 LINUX 是位于所有这些之下的操作系统，让所有这些都保持呼吸。 我们可以在概念上将它包装在一起作为这个 Web 服务器。 我们可能有很多这样的服务器，有点像，坐在一起为网站提供服务。

Phil Hawksworth：这是对 LAMP 堆栈的一种传统看法，如果我们将其与 JAMstack 进行比较，那么，这里有一个关键的变化。 在这里，我们实际上是在向上移动，而不是考虑操作系统并考虑我们如何运行逻辑来交付网站。 在这里，我们假设我们将静态地为这些东西服务。 因此，我们正在执行 ACP 路由，并从静态服务器提供资产。 这可以合理地做到。 多年来，我们在这方面做得非常好，构建了交付静态网站或静态资产的方法。

Phil Hawksworth：这可能是一个 CDN，我们稍后再谈。 但我们感兴趣的领域更多地发生在浏览器中。 所以，在这里，这是我们的标记被传递和解析的地方。 这是 JavaScript 可以执行的地方，这发生在浏览器中。 在许多方面，浏览器已成为现代 Web 的运行时。 现在我们没有在服务器基础设施本身中拥有运行时，而是将它提升到一个级别，更接近用户，并进入浏览器。

Phil Hawksworth：在访问数据时，可能是通过外部 API 进行的，通过 JavaScript 调用这些外部 API 以获取服务器访问权限，或者我们可以将 API 视为浏览器 API，能够与 JavaScript 交互在您的浏览器中提供功能。

Phil Hawksworth：无论哪种方式，这里关于 JAMstack 的关键在于，我们谈论的是预渲染的东西：它们是静态服务的，然后，它们可能会在浏览器中逐步增强以利用浏览器 API、JavaScript ，你有什么。

Phil Hawksworth：所以，让我们在这里做一个小的并排比较。 再次，我只想重申 JAMstack 已经提升到浏览器的级别。 如果我们看到这张图的两侧，左边是 LAMP 堆栈，右边是有效的 JAMstack，你甚至可能会认为，好吧，即使我们使用 LAMP 堆栈构建东西，我们仍然输出标记。 我们仍在输出 JavaScript。 我们可能仍在访问 API。 因此，在许多方面，JAMstack 几乎就像我们之前构建的一个子集。

Phil Hawksworth：我曾经有时将 JAMstack 称为可靠堆栈，因为它保证了我们交付站点所需的一组工具和技术。 但是，无论哪种方式，它都是一种非常简化的网站交付方式，在某种程度上，它消除了在请求时在服务器上执行和执行逻辑的需求。

Phil Hawksworth：所以，这可以做很多事情。 这可以，有点，简化部署，我会不时回电到这个图。 如果我们考虑如何部署我们的代码和我们的网站，对于每一次部署，从第一次部署，到整个开发生命周期，一直到网站的生命周期。 在传统堆栈上，我们可能不得不更改该图表上每个框的逻辑和内容。

Phil Hawksworth：然而，在 JAMstack 中，当我们谈论部署时，我们谈论的是把东西送到 CDN，把东西送到静态服务器，这就是部署所需要的。 构建，运行构建的逻辑类型——可以在任何地方运行。 这不需要在托管 Web 服务器的同一环境中运行。 事实上，它没有！ 它启动了 JAMstack 的密钥。 我们将在请求时发生的事情（为这些静态资产提供服务）与构建时发生的事情分开，这可以是您运行构建然后运行到部署的逻辑。

Phil Hawksworth：所以，这种脱钩是一件关键的事情，我稍后会谈到这一点。 我们非常擅长提供静态文件，将内容发送到 CDN 或将内容发送到文件系统（文件服务器）是我们在过去几年中看到巨大进步的地方。 现在有很多工具和流程可以帮助我们很好地做到这一点。 仅仅举出一些可以很好地为静态资产提供服务并提供工作流以使您的构建适应该环境的服务，它们通常是您可能想象的大型云基础设施提供商，如 Azure、AWS 和谷歌云。

菲尔霍克斯沃斯：但是，还有其他人。 所以，右边最上面的是一项名为 Surge 的服务，它已经存在了几年。 它允许您在构建环境中运行命令并将资产部署到其托管环境。 Netlify，下一个，是我工作的地方，我们做同样的事情，但我们也有不同的自动化。 我可以再去一次。 底部是另一个静态托管环境站点，称为 Now。

Phil Hawksworth：所以，有很多不同的选项可以做到这一点，所有这些空间都提供了不同的工具来尽快访问 CDN。 尽可能以最无缝的方式部署您的网站。 他们都有一些共同点，他们都建立在本地运行的原则之上。 我经常将静态站点生成器视为我们可能在构建中运行的东西，当我们运行它时，它会获取内容和模板之类的东西，也许还有来自不同服务的数据，它会输出可以静态服务的东西。

Phil Hawksworth：我们可以在静态服务器中本地预览。 在任何本地开发环境中都可以简单地执行一些操作，然后将其部署到托管环境，理想情况下，部署到 CDN 以便获得某种程度的扩展。 所以，有了这样的基础，我想解决一个关于 JAMstack 站点的常见误解。 并且我将其公开为将 JAMstack 站点描述为 JavaScript、API 和标记，这对我没有任何好处。 因为普遍的误解是每个 JAMstack 站点都必须是 JavaScript 和 API 以及标记，但是我们忽略了这种事情是我们不必使用所有这三个 - 其中每一个都是， 可选的。 我们可以根据需要使用尽可能多或尽可能少的这些。 就像 LAMP 堆栈站点不一定需要访问数据库一样。 现在，我过去在 Linux 机器上构建了由 apache 服务器提供服务的东西，并且我一直在使用 PHP，但我没有访问过数据库，也不会开始重命名堆栈必然为此。

Phil Hawksworth：所以，如果我们考虑一下什么是 JAMstack 站点，那么它可能是一堆不同的东西。 它可能是用静态站点生成器构建的，比如 Jekyll，从 YAML 文件中提取内容来构建一个没有 JavaScript、根本不使用 API 的站点，我们在 GitHub Pages 之类的东西上提供它。 或者，那将是一个 JAMstack 站点。 或者，也许我们正在使用静态站点生成器，例如 Gatsby，它是在 Jekyll 的 Ruby 环境中，现在这是构建在 React 生态系统中的 JavaScript 静态站点生成器。

Phil Hawksworth：这可能会再次提取内容，它正在组织 Markdown 文件。 它可能会通过调用 API、GraphQL 的 API 来丰富这一点。 它可能在浏览器中做一些事情，比如在浏览器中对填充模板进行 JavaScript 水合。 它可能会在 Amazon S3 上提供服务。 那是一个 JAMStack 网站吗？ 是的，绝对！

Phil Hawksworth：转到另一个静态站点生成器 Hugo，它是用 Go 构建的！ 同样，我们可能会在 Markdown 文件中组织内容，使用 JavaScript 在浏览器中添加交互。 也许不调用任何外部 API，也许将其托管在 Google Cloud 上。 是 JAMstack 吗？ 绝对地！ 你看，我在这里建立一个主题。 使用像 Nuxt 这样的东西，另一个静态站点生成器，现在内置在 View 生态系统中。 也许这是从不同的相邻文件中提取内容？ 同样，我们可能在浏览器中使用 JavaScript 交互，可能调用 API 来做电子商务之类的事情，为它提供另一个静态站点。 另一个像 Netlify 这样的托管基础​​设施，是 JAMstack 吗？ 是的！

菲尔霍克斯沃斯：但我们甚至可能会去，你知道，去到规模的这一端，也。 想想我们自己构建的手工制作的、渐进式的 Web 应用程序、手工滚动的 JavaScript。 我们正在使用 webpack 打包它。 我们可能正在使用 JavaScript Web 令牌并调用 API 进行身份验证，与不同的浏览器 API 交互，将其托管在 Azure 上。 是的，这也是 JAMstack！

Phil Hawksworth：而且，你知道，所有这些以及更多的东西都可以被认为是 JAMstack，因为它们都有一个共同的属性，那就是它们都没有由源服务器提供服务。 他们都不必在请求时访问执行逻辑的服务器。 这些被用作静态资产，然后通过 JavaScript 和对 API 的调用进行丰富。

Phil Hawksworth：所以，我再次重申，JAMstack 意味着它能够直接从 CDN 提供服务。 所以，我只想指出一些影响和影响，因为我们为什么要这样做？ 嗯，第一个概念是关于安全性的，我们已经大大减少了攻击的表面积，在这里。 如果我们考虑（再次回到这个旧图），我们可能不得不处理攻击的地方，我们必须保护负载平衡器、网络服务器、数据库服务器等东西。 所有这些东西，我们必须确保不会被任何类型的攻击，甚至是 CDN 所渗透。

Phil Hawksworth：如果我们能从这个谜题中取出越多的碎片，那么可以攻击的地方就越少，我们需要保护的地方就越少。 几乎没有可攻击的活动部件确实非常有价值。 在 Netlify，我们运营着自己的 CDN，因此我们有幸能够监控通过它的流量，即使在 Netlify 上托管的所有站点，您可能想象的所有 JAMstack 站点，它们都没有在它们上面有一个 WordPress 管理页面，因为它是完全解耦的。 没有 WordPress 管理员，但我们看到了大量的流量，正在探索诸如 WP Admin 之类的东西，寻找进入的方法，寻找攻击媒介。

Phil Hawksworth：我真的很喜欢 Kent C. Dodds 所做的一些事情。 不知道你是否熟悉 React 社区，你可能在过去遇到过 Kent C. Dodds。 他不使用 WordPress，但他仍然路由这个 URL，即 WPAdmin。 我认为他曾经将其路由到 YouTube 上的 Rick Roll 视频。 他肯定一直在拖钓那些已经为此进行调查的人。 但是，关键是，通过以这种方式解耦事物，并且移动发生的事情，从请求时间发生的事情中构建时间，我们可以大大减少我们的曝光。 我们在请求时没有活动部件。 移动部件在构建时都完全解耦。 可能，完全，好吧，必然在完全不同的基础设施上。

Phil Hawksworth：当然，这也会对性能产生影响。 回到我们的老朋友这里，当需要在这些不同的地方执行逻辑时，我们可能想要尝试在堆栈中提高性能的地方。 这在传统堆栈中经常发生的方式是，他们开始添加层，添加静态层，以提高性能。 所以，换句话说，试着找到我们可以开始表现得好像它是静态的方法。 不必在堆栈的每一层都执行该逻辑以加快速度。 因此，我们开始在整个基础架构中引入诸如缓存之类的东西，以及我们可能会在 Web 服务器中发现这样做的明显地方，而不是执行该逻辑，我们希望在不执行该逻辑的情况下立即提供某些东西。

Phil Hawksworth：所以，这有点像迈向伪静态的一步。 同样在数据库服务器中，我们希望将缓存层添加到 cache-com 查询中。 即使在低余额，整个CDN，你也可以认为是一个缓存。 但是在传统堆栈上，我们需要弄清楚如何管理缓存，因为并非所有内容都会被缓存。 所以，这里有一些逻辑。 需要动态填充的内容与可以缓存的内容。 而 JAMstack 模型，一切都被缓存了。 从部署完成的那一刻起，一切都被缓存了，因此我们可以完全不同地考虑它。

Phil Hawksworth：那么，这也开始暗示扩展。 从规模上讲，我说的是，我们如何处理大量流量？ 传统堆栈将开始添加基础设施以进行扩展。 所以，是的，缓存。 我们开始在我们的传统堆栈中到位。 这会有所帮助——在一定程度上。 通常发生的情况是，为了处理大量流量，我们将开始扩展基础设施并开始添加更多服务器、更多部件来处理这些请求，将这些东西计算在内并估计负载是一个很大的开销，它可以对于任何从事技术架构的人来说都是一个令人头疼的问题。 这当然是为了我，这就是为什么我开始更倾向于使用 JAMstack 方法，我只知道一切都来自 CDN，默认情况下设计用于处理规模，以立即处理性能.

Phil Hawksworth：所以，我也想对开发人员的体验表示赞赏，以及这可能产生的影响。 现在，开发人员体验永远不应被视为胜过用户体验的东西，但我相信良好的开发人员体验可以减少摩擦，可以让开发人员更好地建立良好的用户体验！

Phil Hawksworth：所以，当我们考虑开发人员的体验生活在哪里时，以及开发人员关注的领域在哪里：嗯，在传统堆栈中，我们可能需要考虑如何将代码用于所有这些不同的基础设施的一部分，以及它们如何一起发挥作用。 实际上，在 JAMstack 世界中，我们谈论的是底部的这个框。 你知道，我们如何运行构建和它们，我们如何自动化部署以首先获得服务？ 好消息是，在 JAMstack 模型中，您在该构建中做什么完全取决于您。

Phil Hawksworth：这是一个定义明确的问题空间，因为最终，您正在尝试构建可以直接从 CDN 提供服务的东西。 您想使用任何您喜欢的工具预渲染某些内容：无论是用 Ruby、Python、JavaScript、Go 或 PHP 构建的静态站点生成器，您都可以自由选择。 因此，这可以为您创造一个更好的工作环境。而且，它创造了一个让开发人员真正信任的机会，因为 JAMstack 站点的一个真正属性是它们可以更容易地作为不可变和原子部署服务。

Phil Hawksworth：我想暂时离开幻灯片，描述一下这意味着什么，因为不可变部署和原子部署可以……（听起来有点像营销说话）但是我要做的是，我要跳进我的浏览器。 现在……实际上，我要回去一秒钟。 让我……就这样吧。

菲尔霍克斯沃斯：我们来了。 这会更容易。 直接跳入页面。 现在，斯科特，你会告诉我，斯科特，如果你看不到我的浏览器，我希望。 现在，假设每个人都可以看到我的浏览器。

斯科特：一切看起来都很好。

菲尔霍克斯沃斯：太好了！ 非常感谢！

Phil Hawksworth：所以，我在这里做的是使用 Netlify 作为示例，作为服务的示例。 但是，这是一个可以静态托管的站点共有的属性。 因此，当我们谈论不可变部署时，我们的意思是，每次部署代码都必须触及基础设施的许多不同部分，并改变很多事情，这里我们并没有改变网站的状态服务器。 我们正在为发生的每个部署创建一个全新的站点实例。 我们可以这样做，因为该站点是静态资产的集合。

Phil Hawksworth：在这里，我正在查看我自己的网站上发生的部署。 我给你款待。 你来了，这就是它的样子。 它只是一个博客，看起来并没有什么特别了不起或令人兴奋的东西。 这是一个静态生成的博客，但我在这里所拥有的是曾经发生过的每一次部署，都会永久存在，因为它是从 CDN 提供的静态资产的集合。 现在，我可以回到我的历史可以带我去的地方，去看看那个网站，因为它回到了……这是什么时候？ 这是 2016 年 8 月。由于它是一组静态资产，我们能够在其自己的永久存在的 URL 上托管它，如果我什至愿意，我可以决定进入并发布它部署。

Phil Hawksworth：所以，现在，任何正在查看我网站的人，如果我回到我的网站，如果我刷新该页面，现在将直接从 CDN 提供之前存在的资产。 现在，我可以再次导航。 在这里，你可以看到。 看，我一直在讨论这个问题，我在 2016 年使用了这些可怕的术语，比如同构渲染和谈论 JAMstack。所以，这就是现在在我的网站上提供的内容。 同样，因为存在永远存在的相互部署。 我要放上我自己的，有点，安心，我要——这是第一页吗？ 是的。 我将回到我的最新部署。 我将不得不再次关闭，让我回到现实世界。 让我确保这没问题。

菲尔霍克斯沃斯：好的！ 伟大的！ 所以，那么现在，这又回到了为我以前的版本或我的最新版本的网站提供服务。 我会跳回主题演讲。 所以，这是可能的，因为事物是不可变的和原子的。 原子部分再次意味着部署是完全包含的。 因此，您永远不会知道某些资产在 Web 服务器上可用，但其中一些不会。 只有当一切都在上下文中并且一切都在那里完成时，我们才会将网站的服务切换到新版本。 同样，如果您将事物构建为一个 JAMstack 站点，该站点直接从 CDN 作为一堆资产提供服务，那么您可以更轻松地完成这种事情。

Phil Hawksworth：我注意到我的计时器在从主题演讲来回后重置了，所以我想我还剩下六到七分钟。 告诉我，斯科特，如果——

斯科特：所以，是的，我们还有十分钟左右的时间。

菲尔霍克斯沃斯：十分钟？ 好，精彩！

斯科特：不急。

菲尔霍克斯沃斯：谢谢，那应该很好！

Phil Hawksworth：所以，稍微换个角度谈谈 API 和服务（因为 API 是 JAMstack 的一部分），我们可能能够使用的服务类型主要是 JAMstack。 你知道，我们可能正在使用我们内部构建的服务，或者我们可能正在使用购买的服务。 有许多不同的供应商可以为我们做事，那是因为那是他们的专长。 通过 API，我们可能会将内容管理系统中的内容作为服务提取出来，为此有很多不同的提供商，他们专门提供出色的内容管理体验，然后通过 API 公开内容，所以你以前是能够把他们拉进来。

Phil Hawksworth：同样，您可以通过不同的方式为资产提供服务。 像 Cloudary 这样的人在这方面做得很好，可以进行图像优化，再次通过 API 将资产直接提供给您的站点。 或者电子商务呢？ 你知道，像 Stripe 或 Snipcart 这样的地方可以为我们提供 API，这样我们就不必自己构建这些服务，也不必陷入尝试构建电子商务引擎所带来的非常复杂的问题。 同样，身份，来自使用 Oauth 的 Auth0 之类的人。 有很多可用的服务，我们可以通过 API 使用这些东西，无论是在浏览器中还是在构建时，或者有时是两者的组合。

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. 那么，我们该怎么做呢？

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. 谢谢，斯科特。

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. 大家好。 Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. 正确的？ It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth：我真的很喜欢，因为 JAMstack 这个词可能真的会产生误导，因为它试图涵盖很多不同的东西，而我试图在这张幻灯片中多次敲击它的重点是它可以是各种各样的东西的。 它是如此广泛，但关键是静态预渲染和托管网站的核心。 我们很容易陷入关于它需要成为 React 站点的宗教战争。 它必须是一个 React 应用程序，才能成为一个 JAMstack 站点，或者它是一个 React 应用程序，所以它不能是 JAMstack。 但是，实际上，关键在于，无论您是否使用 JavaScript，无论您是否调用 API，如果您预渲染并将内容放入一个性能非常出色的静态主机中，这就是 JAMstack 的核心。

维塔利：是的，绝对的。

Phil Hawksworth：我们很幸运，浏览器的功能越来越强大，浏览器本身的 API 也可以让我们做更多的事情。 因此，这种方式进一步打开了大门，但这并不意味着我们作为 JAMstack 站点构建的所有内容都必须使用所有内容。 根据我们要交付的内容，我们应该开始选择我们正在使用的工具来部署这些东西。

维塔利：当然。 我们这里有多兰。 多兰，我想我知道，多兰。 我有一种感觉，我认识多兰。 他在问，“您是否希望无服务器从 [音频不清晰 00:44:36] 开始倾向于与 JAMstack 无缝集成？ 在 JAM 中称为 A。

Phil Hawksworth：这是一个很好的问题，因为我认为，无服务器功能是——它们与 JAMstack 站点配合得非常好，因为在很多方面，事实上，我想有人曾经问我 JAMstack 站点是否是无服务器的，所以我犹豫不决这个问题，因为无服务器是一个如此沉重的术语。 但是，在很多方面，它都很成功，因为我一遍又一遍地谈论没有源服务器。 没有服务器基础设施供您管理。 事实上，我曾经写过一篇名为“Web Serverless”的博文，因为世界需要另一个流行词，不是吗？

Phil Hawksworth：真的，那是，是的，我们正在构建没有服务器的东西。 我们不想管理这些服务器，而无服务器功能或作为服务的功能正好适合这一点。 因此，在您确实需要一个您想要向其发出请求的 API 的情况下，您直接从浏览器发出该请求实际上是不明智的。 因此，例如，如果您在该请求中有秘密或密钥，您可能不希望这些请求（即信息）暴露在客户端中。 但是我们当然可以代理这些事情，并且通常，传统上，我们需要做的是启动服务器，拥有一些有效地做的只是处理请求的基础设施，为其添加安全身份验证并将这些请求传递给，代理他们回来。

Phil Hawksworth：无服务器功能非常适合这一点。 他们绝对是理想的选择。 所以，我有时会想到无服务器功能或服务功能，几乎就像一个逃生舱，你只需要在服务器上进行一些逻辑，但你不想创建整个基础架构。 你可以用它做越来越多的事情，并为开发工作流提供开发管道，因为作为服务的功能正在成熟。 JavaScript 开发人员能够更容易地构建这些东西。 所以，是的，我真的认为这两件事很好地结合在一起。

Vitaly：好的，这是一个非常全面的答案。 实际上，我最近参加了一个演讲，一位来自亚马逊的前端工程师正在谈论他们正在使用的无服务器和 Lamda 功能——我几乎走了。 他总是在谈论 Docker、Kubernetes 和所有这些东西，Devox World，我坐在那里想，“他是怎么到那里去的。 我不明白这是怎么回事！” 我不知道发生了什么事。

菲尔霍克斯沃斯：没错，但问题是，它曾经是……我是……我接受了我不了解那个世界的任何事情，但我没有任何愿望，因为那是一个完全不同的学科. 这种纪律仍然非常重要。 你知道，设计基础设施的人——这仍然很关键。 但是，现在，我只是觉得我很受诱惑。 作为一个有前端开发背景的人，作为一名 JavaScript 开发人员，我更想在那个世界里玩一玩，因为这些工具正在靠近我。

Phil Hawksworth：我更有可能使用其中的一些东西，并安全地交付东西，而不是仅仅作为我自己的实验，这就是我曾经光彩照人的地方。 所以，感觉就像我们作为 Web 开发人员变得越来越强大，这让我很兴奋。

Vitaly：就像电力别动队一样，是吧？

Vitaly：不过，我确实想问你一件事，这实际上是我们已经讨论过的事情，也许是一周前，但我还是想提出来，因为你在会议中提到的一件事是概念拥有每个部署的独立实例，这真的很酷。 但是，问题是，如果您有一个大型任务，有数万页，您真的不想每次都重新部署所有内容。 所以，基本上，如果你有，比如，如果你主要使用事物的静态方面。 所以，我们有这个想法有一段时间了，我知道这实际上是你上次提出的。 原子部署的想法。

Vitaly：实际上，从字面上看，您在两个不同版本的设置快照之间获得了某种 div。 所以，如果你说，到处更改标题，那么，当然，每个页面都必须重新部署。 但是，如果您更改可能仅影响 1000 页的组件（例如轮播），那么重新部署 15000 页将是有意义的。 但只有这 1000 个。那么，我们能到达那里吗？ 在这一点上，这是一个神奇的想法，还是非常有形的东西？

Phil Hawksworth：我认为这可能是静态站点生成器和这种模型的圣杯，因为当然，您已经确定了可能需要克服的最大障碍。 或者你碰到的最大的天花板。 那是具有许多、数万或数十万或数百万个 URL 的网站——构建可能会变得非常长的概念。 能够根据代码更改检测哪些 URL 将发生更改是一项挑战。 这不是不可克服的，但这是一个巨大的挑战。 了解整个站点的依赖关系图，然后智能地部署它——这真的很难做到。

Phil Hawksworth：因为正如您所提到的，组件更改可能会产生非常深远的影响，但是您——总是很难知道它是如何工作的。 因此，有许多静态站点生成器，这些项目为这一挑战付出了一些努力，并试图弄清楚它们如何进行部分重新生成和增量构建。 我很高兴有一天可能会解决这个问题，但目前，这绝对是一个巨大的挑战。 您可以开始做一些事情，例如尝试在逻辑上共享您的站点，然后再次考虑类似于迁移问题。 好吧，我知道的这一部分在它的种类、它使用的一些资产或那里存在的内容类型方面是独立的，所以我可以单独部署它们。

Phil Hawksworth：但这对我来说并不理想。 这并不是一个完美的场景。 作为概念验证，我已经探索过的一种方法是思考你如何做事，比如智能地使用 404。 因此，例如，非常大的标志（可能是新闻网站）的一个大用例是，当突发新闻故事发生时他们需要一个 URL 时，他们需要首先将其部署到那里。 他们需要在那里获取一个 URL。 像 BBC 新闻这样的东西，你会看到新闻报道会到达网站，然后随着时间的推移，他们会逐渐添加到网站上，但首先到达那里是关键。 因此，构建需要 10 分钟、20 分钟，无论它是什么，这都可能是个问题。

Phil Hawksworth：但是，如果它们的内容是抽象的，并且可能曾经是从 API 调用的。 我提到了抽象的内容管理系统，比如 Contentful 或 Sanity 或其中的一堆。 任何具有内容 API 的内容都会更改将触发构建的内容结构，我们将完成运行，但可能发生的另一件事是，如果您为此发布 URL，然后公开该 URL ，即使构建没有运行，如果有人劫持了那个 URL，如果它的 404 上的第一站不是说“我们还没有得到它”，而是直接点击那个 API，那么，你可以说, “嗯，构建尚未完成以填充它，但我可以在客户端中完成。” 我可以直接访问 API，获取它，然后在客户端中填充它。

维塔利：嗯，有趣。

Phil Hawksworth：所以，即使构建仍在进行中，您也可以开始填充这些东西。 然后，一旦构建完成，它当然不会遇到 404。你会点击那个静态运行的页面。 所以，有技术和策略来解决它，但仍然是一个很长、漫无边际的答案，我很抱歉，但我的结论是，是的，这是一个挑战。 祈祷我们会得到更好的策略。

维塔利：是的，那太好了。 所以，我想知道，所以，在这一点上，我们真的不考虑内容交付方面的性能，而是构建速度方面的性能。 就像构建部署一样。 所以，这也是我们一直在寻找的东西，现在也有相当长的时间。

维塔利：我还想问你一件事。 所以，这很有趣，就像你提到的这种技术。 你是怎么知道这件事的？ 这只是人们倾向于在自己的博客上发布的内容，或者，它是某种媒体，还是有一个中央存储库，您可以在其中获得某种案例工作室，JAMstack 如何 - 公司在卸载时如何移动，或未能迁移到果酱堆栈。

菲尔霍克斯沃斯：所以，目前这片景观有点成熟。 我的意思是，其中一些例子，我认为，我处于一个非常幸运的位置，我在某个地方工作，我扮演的角色是我正在玩玩具，想出有趣的方式来使用它并开始尝试跟他们。 所以，这些概念证明是我可以尝试并尝试解决这些挑战的东西。 但是，我之前提到过，在纽约 JAMstack 会议上展示的一个案例研究，当然，像这样的事件，我们开始看到最佳实践或行业实践和行业方法正在讨论中的事件。 当然，我希望看到更多并进行更多案例研究，以进入 Smashing Magazines 等地方，以便我们可以更轻松地分享这些信息。

Phil Hawksworth：我认为，大公司和企业空间，正在逐渐采用 JAMstack，在不同的地方，以不同的方式，但世界仍然倾斜到那里，所以我认为，每次公司采用它并分享他们的经验，我们都可以从中学习。 但我真的很想看到越来越多的案例研究发表，这样我们就可以特别了解如何克服这些挑战。

Vitaly：好吧，那么，也许只是我的最后一个问题，因为我总是喜欢阅读问题。 所以，在 JAMstack 领域，如果你可以改变一些东西，也许除了部署之外，还有一些你非常想看到的东西。 还有什么能让你真正开心的事情吗？ 那会让你开心吗？ 那会是什么？ JAMstack 的愿望清单上有什么？

菲尔霍克斯沃斯：真是个问题。 我的意思是，如果我们不讨论增量构建，那将是——

维塔利：我们做到了。 现在太晚了这张卡已经通过了。 我们需要别的东西。

菲尔霍克斯沃斯：所以——

Vitaly：我的意思是，就像在一个平台上，如果你看看后面的平台，就会发生很多令人兴奋的事情。 我们有 Houdini，我们有 Web 组件，等等，因为你可以改变所有正确组件的整个格局。 另一方面，我们拥有 SS NGS 的所有神奇、奇特的世界，当然，显然，我们也有单页应用程序等等。 你最兴奋的是什么？

Phil Hawksworth：在这里我会变得迟钝，因为有很多东西正在发生，令人兴奋，并且有很多新功能可以在浏览器中使用。 我真正感到兴奋的是人们表现出克制（笑），正如我所说，回答很枯燥，但我喜欢看到在克制下完成的伟大处决，在深思熟虑的情况下——关于更广泛的观众。 用最闪亮的新 JavaScript 库或新的浏览器 API 构建真的很有趣，也很令人满意，我不知道，浏览器中的划痕和嗅探功能是我们现在任何一天都迫切需要的。

Phil Hawksworth：但我真的很喜欢看到我知道会在很多很多地方发挥作用的东西。 它们将非常高效，将同情现有的浏览器——不仅仅是在那些拥有时髦玩具的 CEO 和 CTO 的办公桌上，还有那些拥有低功率设备的人，或者他们我遇到了具有挑战性的网络条件和诸如此类的事情。 我喜欢看到有趣的体验和丰富的体验，以一种同情平台的方式传递，并且对更广泛的受众有同情心，因为我认为网络的影响比我们这些为它构建东西的开发人员要远得多. 看到以吸引更多人的方式完成有趣的事情，我感到很兴奋。

Phil Hawksworth：这可能不是你必须的答案——

Vitaly：哦，这是一个不错的结局。 太感谢了。 不，这很完美，确实如此。 好吧，我感觉一切都很顺利！ 非常感谢您与我们在一起！ 我要分发给斯科特！

菲尔霍克斯沃斯：太好了！

Vitaly：我只是来玩问答的。 所以，非常感谢你，菲尔！ 我还在这里，但斯科特，舞台是你的，现在！ 也许您可以与我们分享 Smashing TV 上接下来会发生什么？

Scott：我会的，但首先，Phil，我迫不及待地想看看 Scratch-and-sniff API 的实现是如何工作的。 听起来很有趣。 而且，Vitaly，JAMstackify 已经被占用了。

Vitaly：（垂头丧气）上当了？！ 我们可以买吗？

斯科特：不，它存在！

维塔利：嗯，为时已晚。 我总是迟到。

Phil Hawksworth：这本身就很令人兴奋。

维塔利：这就是我一生的故事。 我总是迟到。

斯科特：接下来的成员，我相信，13 号星期四，我们有我的老爸，扎克·莱瑟曼，谈论他最擅长谈论的话题，那就是字体。 所以，他说的是字体实现的五个 Y。 然后，我也对我们在 19 日即将推出的一项非常感兴趣，那就是使用 JavaScript 和 CSS 编辑视频，与 Eva Faria 合作。 所以，请继续关注这两个。

斯科特：所以，下周四又是 Zach Leatherman，然后是 19 日，Eva 将讨论用 JavaScript 和 CSS 编辑视频。 所以，在那张纸条上，菲尔，我再也见不到你了，你还在吗？

菲尔霍克斯沃斯：我来了！

斯科特：关于这一点，非常感谢大家！ 另外，多伦多附近有人吗？ 或者任何曾经想访问多伦多的人？ 我们将在 6 月底召开会议，但还有几张票。 所以，也许我们会在那里见到你们中的一些人。

维塔利：非常感谢你们，其他所有人！

Vitaly：哦，顺便说一句，还有一件事！ 也许 Phil 提到了它，但我们还在 7 月在伦敦举行了 JAMstack 会议。 所以，这也是需要注意的事情。 但我要退出并去拿我的沙拉！ 不确定你——

斯科特：好的，再见，大家！

Vitaly：好的，再见，大家。

这是一个包装！

我们衷心感谢 Smashing 会员的持续和善意支持——我们迫不及待地想在未来举办更多网络研讨会。

此外，Phil 将在下周的 SmashingConf Toronto 2019 和 JAMstack_conf 上担任主持人——我们也很乐意在那里见到你！

如果您觉得这一系列采访有用，请告诉我们，您希望我们采访谁，或者您希望我们涵盖哪些主题，我们会尽快处理。