Frontend platforms, with Matt Biilmann (Netlify) - S04E06
33:09 Share

欢迎收听Console DevTools播客的另一期节目。我是David Mitton，Console.dev的CEO，Console.dev是一个免费的每周电子邮件简报，为经验丰富的开发者提供最佳工具和测试版发布信息。我是Jean Yang，Akita Software的CEO，Akita Software是理解您的API最快捷、最简单的方法。

在本期节目中，Gene和我与Netlify的CEO Matt Billman进行了交谈。我们讨论了在Netlify之前部署代码的情况，随着React变得更加明确，JavaScript生态系统是否即将出现碎片化，状态和数据如何融入JAMstack模型，以及您今天如何才能通过新项目接触到开发者。我们将把时间控制在30分钟内，所以让我们开始吧。

我们现在和Matt Billman在一起。让我们从简短的背景介绍开始。请告诉我们一些您目前的工作以及您是如何走到今天的。感谢邀请我来到这里。我是Matt Billman，Netlify的CEO兼联合创始人。我已经在这个领域工作了一段时间了。我们在2015年3月启动了我们的私人测试版，并且

现在，我们已经为我们的平台引入了大约350万名开发者，并且我们每个月都有大约10亿独立访客访问Eptron和Netlify上的网站。所以目前正忙于管理所有这些。很好，谢谢。我们大多数人都听说过Netlify，我的公司也是Netlify的用户，但对于不熟悉的人，您能否向听众简要介绍一下Netlify是什么？

是的，当然。我们是一个云平台，可以帮助团队构建、部署和运营网站、网络应用程序和网络商店，真正专注于减少围绕为最终用户构建有价值体验的所有摩擦，并让开发人员专注于构建前端代码。我们将处理所有发布管理、基础设施和检测等工作，并帮助您构建成功的项目。

听起来现在真的很容易。我认为那些只……

在过去几年才开始的开发者可能习惯了将代码快速投入生产的惊人体验，但这并不是一直以来的情况，对吧？您能否回顾一下过去，描述一下Netlify之前的状况，以及您是否认为无论您是否在场，这都是不可避免的，以及您认为您在哪些方面真正改变了游戏规则？看到这种构建方式现在已经成为默认方式，真是太神奇了，对吧？在我们刚开始的时候，

我们所处的世界通常是人们将每个网站、网络商店或网络应用程序都构建成一个大型的单体应用程序。如果您查看当时的

主要工具集。如果您正在构建网站，您可能正在使用WordPress、Drupal或Joomla。如果您在大型企业中构建它们，您可能正在使用Adobe Experience Manager、Sitecore和EpiServer。或者，如果您正在构建电子商务，您可能正在为Shopify编写liquid模板，或者正在使用Magento，或者

如果您正在构建应用程序，通常您会有全栈式网络应用程序，对于更前沿的初创公司来说，使用的是Ruby on Rails，对于大型企业来说，通常是Java或.NET等等，对吧？这意味着前端技术几乎完全由后端平台决定。通常，后端开发人员会有更多的组织影响力和更大的权重。

因此，很多时候这意味着人们构建网络体验的实际前端工具集有点像是从他们那里选择的工具集，并且受到它们如何适应需要处理数据访问、业务逻辑和所有这些内容的更大后端方面的很大限制。我早期看到的是，我坚信我们会摆脱这种模式，转向一种模式，在这种模式下，我们将实际的网络体验层

分解成一个独立的层，网络团队可以独立地、希望更快地构建和部署它。但我当时也看到，并没有这种工具、基础设施或工作流程

。因此，在我们开始Netlify的早期，甚至没有为这种网络构建命名。我们必须想出“Jamstack”这个术语来描述这种在自身上构建网络体验层的想法，并且通常看到后端被分成所有这些不同的API和服务，就像现在真正成为主流的所有无头CMS一样，对吧？就像现在也开始成为主流的所有无头商务平台一样，甚至像Shopify这样的大型

参与者也开始思考我们如何成为一个无头商务平台，对吧？这就是我们发现的东西。但我们也看到，在我们开始的时候，这似乎是构建网络的一种更好的方法。

但是人们无法做到这一点，因为每个项目都意味着设置对象存储、发布管理和CDN管理，并弄清楚您需要在服务器上运行的各个部分应该在哪里运行，然后为这些部分设置单独的发布管理流程。然后弄清楚您的前端如何知道内容何时发生更改，设置复杂webhook系统等等。有些团队在这样做，但这很复杂。

并非很多团队，而且这真的很难做到，对吧？所以，在我们开始Netlify之前，我们围绕着如何才能让它变得非常容易做到制定了一个路线图？要使这成为一种真正简单的网络访问方式，需要什么？这成为了Netlify的第一个路线图，对吧？现在，在早期采用者、技术、初创公司等等的背景下，这种方法已经真正成为主流，对吧？我认为，在这个领域中，很少有人会去启动一个新的项目

在WordPress之上，或者选择Ruby on Rails并编写前端而不是在Rails应用程序中编写ERP模板之类的东西，对吧？

但另一方面，重要的是要记住，世界大部分地区仍在以旧的方式进行构建，对吧？我认为我们现在才刚刚达到一个临界点，我们开始看到这种情况真正从完全参与其中的早期采用者转向所有大型中端市场到企业公司的大多数早期采用者，他们正在努力弄清楚，好吧，这显然效果更好，我们可以看到公司从中获得的结果，但我们该如何做到呢？

很好。谢谢，Matt。所以相关的问题是关于Netlify最初的愿景。您是否认为您已经实现了它，现在只是将其传播到世界各地的问题？或者您仍然在实现完整愿景的整个过程中？我认为仍然还有很长的路要走。

我认为我们已经实现了部分愿景，对吧？我认为我们开创的这种前端云层，以及我们真正构建的第一个云层，对吧？就像现在它也正在成为一个竞争激烈的领域，这是一个健康的迹象，对吧？这表明它现在是一件真实的事情。不仅仅是Netlify或这个。

现在已经有许多这样的平台了，例如Gatsby Cloud、Roussel、Amplify Console、Azure Static Web Apps、Cloudflare Pages等等，对吧？它开始成为一个真正的类别，而我们从一开始就是这个类别的领导者。但我认为，特别是当您考虑这些大型公司采用这种方法时，在弄清楚所有这些不同接口之间的接口方面仍然有很多工作要做

API和服务，它们既在内部也有外部购买，以及它们如何适应架构。如何以简单的方式让所有这些数据都可供您的网络团队使用。您如何才能避免感觉每个项目一开始都需要大量的样板代码才能将数据输入和输出，并连接服务？您如何在该层上处理正确的权限和身份验证层？

在某种程度上，在架构师和负责以下方面的人员之间，在这个接口层中还有很多领域需要改进：我们如何看待这个问题？不要把它看作是一个又一个的网络项目，而是把它看作是我们公司的架构。然后我认为，另一方面，在我们更多地处于营销网站或电子商务领域，甚至应用程序领域时，也仍然有一些工作要做，对吧？我认为

当我们正在重新调整整个格局时，您在旧世界中从WordPress或Groupon获得的一些工具，或者从旧世界中的一些全栈框架获得的一些工具，例如让您的营销人员能够轻松地进行

对登录页面的可视化编辑等等，或者让产品经理能够轻松地在您的应用程序中设置实验等等。我认为，随着我们对数据源和UI等的解耦，我们在构建架构模式方面有一些工作要做，将这些东西重新组合在一起，并让每个人，而不仅仅是开发人员，都能感觉到他们拥有比他们离开的那个更好的开发世界。您认为有多少与

语言和框架相关？我想您已经谈到了WordPress和Drupal，它们是PHP，并且仍然非常流行。但我认为，现在从头开始构建东西的更现代化的方法是TypeScript。您最近收购了Gatsby。还有Next.js以及各种其他

框架。Swellkits、Solid、Noxt、Beatpress、Astro，对吧？这是一个非常广泛的领域。我认为它的耦合方式是，现在所有这些网络开发人员都有为他们构建UI而构建的框架，而之前他们是在为

从数据库中获取数据、围绕它定义业务逻辑、运行服务器端工作负载等等以及在其上折叠一些前端内容的框架中工作的，对吧？我认为这是其中的一个很大的区别，但也是一个挑战，对吧？当我们开始解耦这些部分时，就会出现一种重新耦合，好吧，我们如何才能像以前在WordPress设置中那样直观地将您的产品和商务数据放入前端框架中，并让他们感觉彼此了解，以及我们如何在这样一个世界中轻松地为其他利益相关者构建工具，在这个世界中，您知道前端框架层是快速发展的，并且可以发生很大的变化。但对我们来说，这一切都是关于

启用构建这些框架并在该框架空间中快速移动的能力。我们从未相信过……我们这个领域的其他公司已经围绕一个框架构建了更多整体堆栈的策略，这有一些明显的优势，但我们始终更相信这一点，尤其是在大型公司中，您天生就会拥有许多不同的框架，尤其是在时间推移的情况下。

我们更倾向于这样想：如果我们知道这是一个不断变化的格局，那么我们如何才能很好地支持每一个框架，同时又能很好地构建适用于所有框架的工具？是的，我认为这非常有见地。软件本身就是异构的。我相信任何试图使软件同构的公司都在徒劳地

进行太多斗争。是的。是的。尤其是公司规模越大，对吧？您开始进行收购，这会带来他们自己的技术堆栈。您开始拥有您没有资源迁移到新事物的遗留项目，对吧？这只是任何大型公司的现实。对于处于早期阶段的初创公司甚至增长型初创公司来说，情况有所不同，它们的技 术堆栈可能更简单，对吧？但是一旦您拥有一家存在了一段时间的真正大型

公司，它也将拥有一个非常庞大的技术堆栈，其中包含许多异构元素。没错。热门工具、有用的工具，这些都会随着时间的推移而改变。因此，任何一家成立超过10年的公司，您都不能指望再使用相同的东西了。是的，我认为这非常、非常聪明。是的，尤其是在JavaScript领域。

框架生态系统。总是有新的闪亮的东西，但React似乎长期以来一直是流行的框架。您认为这是因为它设计的方式如此流行吗？我想是因为更容易理解引入组件，所有这些东西？您认为它为什么能够保持其地位？

所以，具有讽刺意味的是，我认为它可能即将发生一些变化，因为在某种程度上，我认为它保持其地位是因为它具有相对较小的表面积，并且很长时间以来都相对相似，对吧？团队一直在努力进行一些非常大的改变，但他们也花了很长时间。因此，实际上，表面积相对简单。我认为

关键价值在于能够将UI视为可以隔离工作的组件集。我认为它也是一个非常不固执己见的框架。因此，如果您查看一些最大的React，如果您查看React和网络上的存在，很容易认为它完全是关于Nix和Gatsby的，但最大的一个是Wix，对吧？他们为其组件系统采用了React，对吧？到处都是。如果您阅读关于

WordPress的教程，并且如果您只是查看React和Gutenberg，您会看到许多关于如何使用React组件来构建WordPress网站的可视化页面构建的教程等等，对吧？所以，我认为人们可能低估了它如何通过存在于一个非常异构的世界中来达到这种市场渗透率，对吧？到处都是。

我认为现在正在发生一些有趣的事情。我认为React团队现在正在采取一种更明确的方法，并且显然与Next团队进行了大量合作。我认为这为他们提供了一些非常酷的机会，对吧？例如，构建一个对世界有更强烈观点的端到端框架。但我认为这也可能意味着其他一些工具可能会开始更贴合这种图片。就像我们只需要组件一样。不要对端到端世界应该是什么样子提出全部意见。

我们可能会开始看到整个空间中出现更多波动。——是的，非常有趣。我想，如果您今天要启动一些新的东西，比如与React竞争，您会去哪里？我想问题是，如果Netlify今天开始，您将如何接触到合适的受众？

对于我们Netlify来说，我们仍然只是试图为您提供最佳工具，无论您选择什么前端框架，对吧？例如，我们有一个专门适应Nix的运行时层，它将为您提供仅在我们平台上可用的中间件功能等等，对吧？但如果我今天要启动一个新项目，我的意思是，我会……

我会看看我正在构建什么样的项目。例如，在Netlify，从一开始，我们总是对我们的主要营销网站和我们的应用程序使用非常不同的技术。因此，我们的应用程序是一个纯React应用程序，不使用任何框架。它实际上是React、Redux、单页应用程序。这很有意义。我们所有的用户基本上都是

桌面用户或快速设备上的用户，并且都是登录体验，对吧？我认为这是有意义的，然后我们的营销网站总是像非常轻量级的JavaScript，最初是用Hugo构建的，今天我可能会用Astro来构建它，对吧？我认为这是我会考虑的事情之一，我认为这些不同的框架

都有机会在某些用例中变得非常出色。但是，如果他们试图在所有用例中都表现出色，那么自然会有一些更专业的框架在其中一些用例中表现出色。我认为Astro看起来像是围绕着这样一个概念构建了一个非常出色的开发者体验：让我们构建没有JavaScript和少量交互性岛屿的内容驱动型网站。

有很多网站最适合以这种格式实现。SolidJS开始看起来对以下方面非常有趣：嘿，我实际上是想构建一个应用程序。我认为它正在……

获得React团队通过React服务器组件、悬念和钩子等等开始实现的许多优势。但在添加非常复杂的思维模型的同时，我认为Solid开始展示了一种获得这些好处的方法，但思维模型非常简单，您只需要几个核心原语，而所有内容基本上都是这些好处的副作用。

但同样，我认为即将在这个领域发生一些碎片化，因为随着React团队变得更加明确，重新简化特定用例并构建具有更简单思维模型的工具的机会就更多了。然后我认为从长远来看，我们可能会看到一些更剧烈的变化。就像现在，我们正在看到围绕生成式AI发生的事情一样，

它可能会改变我们随着时间的推移与计算机交互的方式，对吧？它已经几乎达到了您可以想象将一些工具缝合在一起的边缘，并且您将与程序进行这种对话，对吧？而不是与人类。

我认为，随着这种情况的发生，这将开始彻底改变我们消费内容和商业的方式等等。它可能会改变构建网站的意义。因此，如果像5年、10年后，React和Solid或Next和Gatsby和Astro之间的区别几乎不再是相关的事情，我也不会感到惊讶。谢谢，Matt。我想触及的一件事是我知道……

在Netlify的早期，您提出了这样一个想法：每个开发人员都应该能够非常快速地在Netlify上构建自己的博客。这是您坚持不懈的事情。这是您告诉团队永远不能打破的体验。我喜欢这个想法。我很想了解更多关于您是如何想到将这种互动作为关注重点的？随着Netlify的发展，它是否发生了变化？

我们的整个模型随着时间的推移发生了很大的变化，并将继续发展，尤其是在我们现在我认为即将从这个早期多数转向弄清楚我们如何真正将它交付到早期多数和所有这些新一代采用者手中时。但在早期，

当我们开始将Netlify作为一个新产品时，对吧？首先，我们从一开始就真正考虑过，并且效果很好，对吧？我们真的把我们的旅程看作是在同心圆中移动，对吧？首先，我们必须……

满足该领域的核心创新者。我们真的寻找当时正在构建的人，构建静态站点生成器，构建单页应用程序框架，并在这些是工具的地方工作等等，以便接触到那些已经尝试通过项目构建自己的内部Netlify项目的人，并将他们作为我们的第一批采用者、第一批布道者，对吧？像

接下来是真正的早期采用者群体，那些总是花周末时间寻找新的技术来学习和采用的人，他们受到持续的好奇心的驱动，甚至他们在市场上的竞争价值也是如此，因为他们总是知道接下来会发生什么以及什么是热门事物等等，对吧？所以下一个问题是，我们如何接触到他们？我认为这很大程度上是关于在他们……

周末项目时，他们会构建什么？他们想构建的一些我们可以让他们真正轻松实现的事情是什么？如果没有我们，他们可能根本不会构建的东西是什么，对吧？当围绕这种构建方式的空间很大程度上是关于静态站点生成器等等时，我们早期看到了一个机会，对吧？它们是开发人员构建博客的好方法。

作为开发人员，您通常希望所有事情都发生在文件系统和GitHub中，对吧？您不一定喜欢在某个内容UI中编写博客文章的想法，而不是在Visual Code中编写它们并靠近中间。因此，我们认为这是一个很好的起点，对吧？像每一个，尤其是每一个这样的开发人员，他们也非常热衷于分享他们在周末学到的东西，并且为此需要一个博客。

但公平地说，我们很多人也很不擅长实际撰写任何博客文章。因此，我自己也有一种倾向，那就是在周末重新构建您的博客并撰写一篇关于它的博客文章。

您是如何构建博客的，然后您可能永远无法写更多博客文章，但您会写那篇，对吧？因此，我们认为这是可以与开发人员的想象力联系起来并帮助他们真正将某些东西带到世界上的关键因素之一。以及从Netlify获得的顿悟时刻的代表，对吧？一旦您构建了它，您就会感觉到，哇，我刚刚推送到get，我的更改立即生效了，对吧？我从像

找到一个站点生成器到拥有我可以与他人共享的URL上的内容，只花了30秒的时间，对吧？这与之前世界的样子相比是一个如此巨大的变化，我认为任何尝试过这种体验的人都会感觉到，等等，这总体上感觉非常强大，对吧？然后我们可以将它与以下内容联系起来：当该开发人员在工作时，并考虑以下内容时，

哦，哇，我们有一个新的活动即将到来，对吧？我们需要围绕它构建一个新的网站，并且需要准备好处理流量。我们不知道CMO会投入多少预算等等。我刚刚尝试构建这个副项目，它比我尝试使用公司的标准工具构建这个活动网站所获得的任何体验都要好得多。也许我可以获得我的工程经理的许可，使用Netlify来构建它。然后我们开始进入一家公司，然后我们可以开始建立关系，对吧？所以早期，这非常符合我们的预期。现在，当然，随着我们的规模扩大，越来越多地参与到大型企业项目中，

其中一些动作开始发生一些变化等等，对吧？但我们仍然希望坚持我们的目标，即为

任何想要在今天可能不仅仅是写博客，而是可能尝试SolidJS和PlanetScale并使用在边缘运行的Dino构建一些很酷的东西的兴奋的周末采用者提供良好的体验，对吧？让他们感觉到，等等，我可以在几秒钟内设置所有这些内容，并编写一个与数据库对话的全球分布式应用程序，而无需做任何事情，只需编写代码并将其推送到get up

- 您认为数据和状态故事在那里是什么？它是否通过HTTPS本质上连接到互联网，连接到像PlanetScale或Neon这样的东西（如果您想使用Postgres），但本质上让数据位于其他地方，因为在我很久以前构建应用程序时，这始终是一件非常奇怪的事情，我们会拥有一个单独的后端，数据库位于尽可能靠近应用程序的位置以降低延迟。- 是的，所以我认为，

同样，我仍然非常相信这一点。如果您去大型公司，看看他们将如何构建东西，我认为，缺乏更好的词语，像这种Jamstack架构可能是他们将要采用的架构，其中网络开发人员将负责网络UI，但他们可能不会

像我一样工作，我认为如果您去那些大型公司，如果您以我们的一些客户为例，例如Twilio或Dr. Sign或Unilever等等，我认为他们不会突然像

将他们的核心业务数据放入全球分布式边缘数据库中，并让他们的前端开发人员直接通过SQL和边缘访问这些数据，对吧？他们可能仍然会拥有像核心API团队这样的团队，他们可能更多地使用Go、Java或C Sharp等语言进行工作。在某些情况下，可能是Rust。在某些情况下，是Ruby on Rails和Python等等，这取决于它们的位置，对吧？像

构建API，然后他们可能会组建围绕数字体验的团队，构建应用程序、网站和电子商务以及获取这些内容的移动应用程序。所以，我认为您将看到网络团队直接在边缘构建、直接使用Nia、PlanetScale、Cockroach、Fauna等等的用例。

它们可能更适合早期阶段的初创公司、绿地项目等等，对吧？公司越大，您就越会开始真正地将数据层与一个限制访问的API解耦，这使得架构师更容易说，现在您可以直接在它之上构建移动应用程序和网络应用程序等等。您无法弄乱数据。因此，在这些情况下，我认为它最终可能会变成更多……

缓存故事和现实，对吧？例如，您如何获取来自这些API的数据，并获得围绕它的真实边缘缓存优势，并以在构建边缘应用程序时也真正快速的方式将其提供给构建网络应用程序的团队。但我认为这不会是一个像我们将所有业务数据移动到边缘数据库这样的问题。

有趣。因此，API我想是在与边缘对话，您仍然使用这种方法构建所有前端和应用程序，但API将与集中式数据一起存在。我认为这将是典型的方法。我认为我们从Shopify及其Remix收购以及围绕它的策略中看到了一些这样的情况，其中他们

许多项目，主要是试图使用Remix，都会遇到数据不在边缘的问题。因此，在边缘构建通常会使事情变得慢得多，因为现在您有……

您正在尝试对其他地方的数据库进行大量往返，而真正让某些东西出现在您的用户面前需要很长时间。但对于Shopify的用例，如果您只是与它对话，您只是在Shopify的API之上构建一个无头UI，那么Shopify的API已经使用全局缓存层构建，并且在全球范围内非常快，对吧？因此，这对于这种电子商务用例来说开始变得非常有意义。然后在我们这边，部分原因是，

我们收购 Gatsby 的原因是为了开发他们启动的名为 Valhalla 的产品线，这实际上是一个构建内容中心的想法，您可以使用 Gatsby 源插件来定义如何从不同的数据源获取数据并将其提供给 Web 开发人员，

然后，我们能否拥有一个系统，该系统可以使该数据层保持同步，并在构建时、边缘以及运行时为您提供非常快速的数据层，您可以在其中访问该数据，而无需进行完整的往返行程到实际的 API。并且您可以以统一的方式跨可能已经过优化的数据源（例如 Shopify 的 API）执行此操作。

或者就数据源而言，可能真的不像您的旧 Drupal 安装或您的 PIM 或您需要实际从中获取数据并将其输入 UI 周围的数据一样，对吧？我认为

这为我们提供了巨大的潜力，可以帮助公司解决以下问题：我们如何让 Web 团队跨许多不同的数据源构建这些类型的用户体验，但我们得到了一些保证，即它始终表现良好，我们不会突然让边缘代码尝试进行大量往返行程并减慢所有速度或通过动态请求或类似内容压倒我们的 API。

随着时间的推移，我们可能不会是唯一一个帮助公司遵循这些模式的人。谢谢，马特。另一个问题是，Web 和工具的转变是否导致您重新考虑您的

您的一些路线图或目标？如果是这样，它们是什么？我的意思是，这是一个快速变化的空间和环境。因此，我们始终必须保持领先地位，对吧？就像今天一样，我们有一个名为框架支柱的整个工程支柱，人们一直在努力工作

确保框架作者可以提出的任何内容都集成到我们的部署、操作和运行方式中，对吧？因此，其中一些变得更具反应性而不是主动性，而另一些则更具主动性而不是反应性。我会说我们看到人们对在边缘运行流渲染非常感兴趣，我们最初在构建边缘函数时，

在第一次迭代中，我们并没有过多考虑该用例。我们更多地考虑的是在边缘进行更简单的决策，例如路由决策、个性化、拒绝服务、身份验证决策等。现在我们看到，当我们对该层进行重新调整并在去年年初启动我们当前版本的边缘函数时，该层

这实际上是围绕着，好吧，我们看到人们会希望在边缘构建完整的流渲染服务，这感觉有点像应用程序，并且需要更多的权重。我认为随着时间的推移，

人们也会发现其中的一些复杂性，并且在何时想要这样做以及何时不想这样做之间会有一些区别。但这绝对是我们所说的其中之一，好吧，我们需要为此做好准备，并为此成为一个伟大的平台，即使一开始我们并没有设想架构会这样发展。是的，这很有道理。好吧，在我们结束之前，我有两个闪电般的问题要问你。第一个问题是，您目前正在玩哪些有趣的开发工具或一般工具？

所以现在我正在玩 SolidJS 和 Astro 以及 ActivityPop 协议。看到它真的很酷。我的意思是，在 Netlify，我们一直都有这样的想法：让网络变得更好，因为网络是一种开放的平台，没有任何单一的公司所有者，对吧？

我认为很多人通过 Twitter 的收购以及那里发生的一切，都对这意味着什么有了某种感觉。当您的平台有一个所有者时，该所有者也可以突然改变主意，去做您希望做的事情，对吧？我认为这重新激发了围绕构建联合社交服务的整个环境，无论是在 Mastodon 环境中还是在 Noster 等工具中。这是我发现很吸引人的事情。

非常有趣，并且与 Web 的含义的一些根源很好地联系在一起。所以我正在玩一些这个。然后，当然，像其他人一样，我正在玩新的生成式 AI 工具。是的，我真的很希望 RSS 回来。当我看到一个博客并且没有 RSS 提要时，我总是很生气。没错，没错。但我认为这也会有很多有趣的潜力，可以很容易地添加

例如，将活动弹出式联合添加到您的个人博客中，例如，只需进行一个发布，您就可以打开它，而无需运行一些多用户掌握的实例，您只需部署一个博客，但让它与该生态系统交互。为什么这不能微不足道？是的。最后，您的当前技术设置是什么？您每天使用哪些硬件和软件？

在家，我使用的是旧款 MacBook，甚至不是现代 M1。所以我还没有完全更新。总的来说，我一直喜欢尝试坚持使用相对简单的工具。我一直不喜欢那些使事情过于复杂的工具。

作为开发人员，我太复杂了。我一直寻求简单性和那些提供长期可靠性而不是短期优势的复杂工具，对吧？因此，通常情况下，我的所有工具集在这种方式下都非常基本。优秀。好吧，不幸的是，我们只有这么多时间。感谢您的加入，马特。是的，谢谢。这很棒。是的，谢谢。感谢您的邀请。

感谢收听 Console DevTools 播客。请在 Twitter 上告诉我们您的想法。我在 David Mitton，您可以关注 console.dev。不要忘记在您的播客播放器中订阅和评价我们。如果您正在玩弄或构建任何有趣的 DevTools，请与我们联系。我们的电子邮件在节目说明中。下次见。