【访谈实录】对话 Lee Robinson ：聊聊前端的未来 & Vercel

本文是对「Web Infra 大咖面对面：聊聊前端的未来 & Vercel」直播内容的全文翻译，直播时长 1.5 h，全文大概 1.2 万字，阅读时间约 40 分钟。

直播回放链接：https://live.juejin.cn/4354/vercel

阅读本文产生的任何疑问都欢迎评论探讨，如有翻译不当欢迎斧正。

开场

Anne: Hi Lee, 你好，你现在在哪呢~

Lee: 我现在在 Des Moines, Lowa, US (美国爱荷华州德梅因)。

Anne: 我这边是晚上八点左右，你那边呢？

Lee: 现在是早上6点 😴

Anne: wow! (对于你来说)刚醒来就要做很多事，不好意思这次活动让你起那么早，我相信很多人已经认识你了，能对在看直播的朋友们来个更深入的自我介绍吗？

Lee: 当然可以，我是Lee，Vercel开发者关系团队负责人 (Director of Developer Relations at Vercel)，Vercel是一家可以帮你轻松部署前端项目的公司，我带领团队致力于基础的（开发者）帮助教育，以及发展开发者社区。

Anne: Cool ! 在此之前我做了个小问卷，收集了下大家主要想听你分享什么内容以及想要什么样的分享形式等问题，调研结果是大家更想要一半分享一半 AMA (Ask Me Anything)。你准备好开始分享了吗，之前有准备吗 😊 ？

Lee: 当然有的，我来分享下我的屏幕。

基础概念

ok, 今天我想聊聊关于前端的未来，包括前端是如何演进的，会聊聊 Next.js ，当然也会聊聊 Vercel ，最后会留点时间进行 Q&A。

首先，我先讲一下概念，第一个是CDN 和边缘网络( Edge Network )。

CDN 可以帮你把静态资源存储到世界各地离用户更近的地方，可以看到你在某个地方会有一个源服务器( Origin Server )，那可能有你的数据库，然后你在这（服务器和用户）之间搭建了 CDN（来分发存储静态资源），让你的用户能更快地访问你的网站。

现在不同的是，这个 CDN 网络是边缘网络，可以执行代码，这对我们接下来要讲的未来前端非常重要，我希望我们先明确这一点。那么这个和我们的前端应用有什么关系呢？

现在人们构建前端应用的方式发生了很大变化，前后端的分离越来越清晰，数据在前后端之间如何流转，很大程度取决于日益增长的成千上万的 REST APIs 和 GraphQL APIs，开发者可以自主选择喜欢的获取数据的方式。现在像 Next.js 或者其他框架给你提供了一些api来进行数据交互，并且你可以把前端分发到我刚刚提到的全球边缘网络。

我们有很多常用的方法来把数据展示到屏幕上，每一种都有它自身要考虑的因素。我们先来聊聊客户端渲染 (简称 CSR , Client-Side Rendering)，这种大家比较熟悉的方式，比如 react 和 vue. 首先给浏览器发送一个初始的 HTML，不包含任何数据，就像一个壳子(shell)，所以浏览器一开始只能渲染个空壳，然后再去获取数据并渲染到屏幕上。

在服务端渲染(简称 SSR, Server-Side Rendering)中，在预渲染(Pre-Rending)环节有点不同，这时我们已经能在服务器获取到数据了，可以让返回的初始HTML包含首屏渲染内容，再在客户端执行叫做注水(hydration)渲染的过程，就像 React / Vue 以及它们的SSR框架 Next.js / Nuxt 做得那样。举个例子，服务器端返回的 HTML 包含这个按钮，但是是置灰的（不可交互），在客户端注水(hydration)渲染之后，这个按钮就变成可交互的了。在客户端执行 JS 前，页面是没有可交互能力的。

现在，Next.js 及其他框架里，包含太多这种缩略词，它们每个都代表一种获取数据然后渲染的方式。

• CSR：Client Side Rendering 客户端渲染
• SSR: Server Side Rendering 服务器端渲染
• SSG: Static Side Generatio 静态网站生成
• ISR: Incremental Static Regeneration 增量式网站渲染
• RSC: Remote Service Component 远程服务化组件

这些我们暂时不需要研究太多，它们都只是获取数据然后渲染的一种方式。

译注：ppt标题有个笔误，应该是 Static(SSG/ISR)

Edge

我们来看下静态生成(Static)相关的渲染方式，我们生成静态文件并发布到 CDN，这样有两个好处：

• 始终遍布全世界 Always global
• 始终可用 Always online

如果你服务器挂了，你不需要担心网站直接不能用了，因为你已经生成了持久的静态资源，并且可以将这些静态资源发布到世界各地。当然，这样也经常有一些缺点：

• 不容易做逻辑实验（比如 A/B Test）
• JS体积更大
• 更易导致布局偏移(Layout Shift)

右边是传统的 SSR，这种方式并不能 Always gobal ,也不能 Always online. 为了让你的应用能让全世界访问，要么花费很大的代价在世界上每个地区都架设服务器，要么建立在serverless架构上，把代码发布到世界各地，这么做更省钱，但也有其他的问题，比如说冷启动的情况，类似 AWS 这样的服务需要很长时间才能实际启动和执行你的代码。

并且这并不能保证 Always online, 如果你的服务或者 API 挂了，你的网页就直接不可用了。但是 SSR在下面这几点表现比较好，比如在服务端就可以将用户划分到不同实验组，执行不同的代码逻辑，减少客户端执行的 JS 代码，以及初始返回的 HTML 就包含基本的页面结构，可以减少布局偏移。

我们把上面说的这两种结合起来，就是我刚刚提到的 Edge SSR。边缘网络的关键特性是可以在世界各地运行代码，这个特点是它与生俱来的，我们可以不断优化静态生成的部分和服务端渲染的部分。所以保证可用性的唯一办法，是尽可能静态生成。

Anne:  sorry, 可以详细解释下吗，因为我第一次听说边缘网络这个概念，就像有人第一次跟我说兄弟你知道微软(Microsoft)吗，多解释下吧~

是的，新的概念有点难以理解，所以这里用要解决的问题来说明它，我们接着看，比如这个例子，事实上每个 SSR 应用都会有这个问题：全量数据请求或者什么都不请求。(I'm doing all or nothing data catching)

来看左边这部分，我发送了两个请求，一个请求去检查用户是否登录，另一个每分钟从去中心化的内容管理系统(Headless CMS)获取信息。在最慢的API调用结束前之前，用户基本只能对着一个空白页面，直到你获取到数据并最终给客户端返回HTML。

当你使用 Serveless 函数的时候，这个问题会被放大，因为我们有个循环请求。

即使很多底层架构做了很多很多优化，比如 Firecracker^[1], 但依然有不可共享(none-shared)的时间去初始化你的代码和连接数据库。所以每个请求打进来，并不能尽最大限度的重用资源。

ppt上半部分，每次请求会打到不同实例，并重新初始化环境。

对于Edge模式，你可以通过 Vercel Edge functions 或者 Cloudflare workers 或者其他一些工具来部署边缘运行时环境(Edge Runtime)，这里并不是在运行 NodeJS，而只是 V8 引擎和 Web APIs，与其占用整个实例环境，不如只占用其中一部分，这样可以更快。我们看这个例子，多个请求可以打进一个实例，可以更好的复用环境，在冷启动的情况下，差不多要比上面快100ms。

那么如果是 SSR 的情况下呢？当 SSR和 Edge Runtime 结合起来，而不是被阻塞请求打满时，这意味着什么呢？从服务器到客户端，可以“流式”(Streaming)传输，这意味着当数据可用时可以立刻渲染给用户。这种流式传输在大量请求下更加可行，并且可以利用 Edge Runtime 带来的性能优化。

所以这在实践中会是怎么样呢？当你可以使用 Edge Runtime，并且可以精细地控制打包的静态资源，前端的未来会怎么样呢？

看上半部分是一个旧的示例，左边全部是静态生成的，你看到的所有内容都是直接生成的 HTML。

右边则全部是动态的，每次请求的内容都是不同的，每次渲染都会获得当前的最新信息，用户每次获取信息都可能是一个 A/B Test 。

这两种都是未来前端的发展方向，各自都有各自的收益，那么如果我们把这些收益应用到一个页面的不同地方呢？

在组件维度进行控制，而不是整个页面全部静态生成或动态获取，这就是 Edge Runtime 可以解锁的能力。

当前有些大厂已经用上了这种特性，最大的应该是 Apple，已经开始使用 Next.js。

沃尔玛也在使用 Next.js。

Hulu 也在使用 Next.js。

与这种全球性公司的合作交流，可以帮我们不断完善 Edge，我们可以在全球范围实现理论上的最佳性能优化。

Vercel

所以我也想聊聊 Vercel，因为 Vercel 是一个产品，也是一个平台，试图帮人们走向前端的未来。我们提出了许多假设理论，比如刚刚谈到的如何利用 Edge 提高性能，使用 Edge Runtime 进行渲染，我们正在努力实现这些假设。

所以我会简单展示下我们的产品，我觉得展示下用户实际上是怎么使用我们产品是很有趣的。

1. 编写代码 Code

我们从编写代码开始，你在本地编辑器或者浏览器里使用类似 Next.js Live 的东西，来编写代码并与团队协作，然后可以立即看见更新，所见即所得。

2. 提交代码 Commit

3. 构建 Build

然后我们提交代码到 Git Workflow，并自动基于最新提交进行构建，你可以看到一条新的 comment，链接可以看到本次构建详情，这里有构建原因，并且可以快速看到代码预览链接，我可以和我的团队共享。

4. 测试

实际上，我们可以在每次推送都检查性能和可靠性。我们进行了一系列的快速验证来保证每次变更的可靠性。这不仅可用，还达到了我们定义的性能阈值 (Performance Thresholds)。

5. 预览 Review

你可以获得预览链接，来验证你的更改，并且可以将链接发送给你要交付的人或者你的小伙伴，所见即所得。我在 Next.js Live 中，可以与其他人合作，可以发表评论或者直接在屏幕上圈出来，并说“你的这些更改看起来很棒”。

6. 发布 Deploy

继续，让我们合并这些更改，然后可以将最新的代码部署到边缘网络。边缘网络在全球范围都有出色的性能，并且在可能的情况下尝试采取边缘运行时(Edge Runtime)来减少延迟。

7. 监测 Measure

Next.js 内部有一个新的改进，当你部署完之后，如果你想确保你的真实用户的体验是好的，我们内部有个叫做 "Vercel Analytics" 的工具，可以测量你的网站性能，以确保更快的用户体验。但目前仅限于你的用户和你能看到的这些指标。

几个问题

我想稍微调整下，先回答下提前提的几个问题，有几个是关于 Rust 和 WebAssembly 的，然后 Vercel 是如何看待前端的未来，我想之后再聊。

1. 打包器 Bundler

先简单谈下基础的东西，Next.js 内部在使用 Rust，首先我们要为生产环境打包我们的代码，我们有一堆不同的 JS 文件，或者 CSS 文件，甚至TS文件，所有这些文件通过一个打包器，输出为生产环境可运行的文件，现在这个打包器用的是 Webpack，但这里有足够的时间来更改为 SWC（一个正在成长中的打包工具），它可以代替 Webpack。为什么要这么做？因为比你使用过的任何打包工具都快。

2. 编译器 Compiler

用 JS 或者 TS 写的代码需要经过编译，左边是 JSX 代码，使用最新的JS语法特性，经过编译后转化为浏览器可以执行的原生JS代码，并且这个编译过程已经可以通过 SWC 进行，SWC 是基于 Rust 的下一代快速构建工具，但这个部分是相对独立的。

3. 压缩

第三步是压缩，左边是编译后的代码，但依然保持着可读性，为了更好的性能我们可以将编译后的代码压缩成更小的体积。压缩过程依然可以通过 SWC 进行。

当展望 Rust 和 Webassembly 的未来时，我们押注于 SWC，我们认为 Rust 可以让 Next.js 更快，这已经被证实了，这是 Next.js@12 的一项巨大投入，我们已经看到构建的速度大大提升了，本地开发重新加载的速度也更快了。

下一个重要变革是 SWC 刚刚发布的允许用户编写的插件系统，Rust 插件可以为浏览器生成WebAssembly，这是一个很大的课题，我们还没有真正深入研究，这是一个全新的领域，并且非常令人兴奋。

能够通过自己的代码进行拓展，同时可以满足你或者你的团队想要的性能， 这就是 Rust 和  WebAssembly 我想聊的。

还有几个问题是问我开发者关系(Developer Relations)是做什么的？是我的首要工作吗？

我认为是教育开发者和发展开发者社区。不仅仅是Next.js还有更大的社区，以及其他优秀的开源工具，比如 Turborepo^[2], SWC, SWR^[3], Webpack, 当然还有 Next.js。我团队的一些人，包括我在内，帮助发展这些开源社区，创建教育内容来帮助开发者们取得成功，去处理 issue 探讨他们遇见的困难，帮助他们了解使用我们的工具。所以我团队中有5个人，每个人负责一个不同的领域，来尝试帮助这个领域的开发者取得成功。

这个解释差不多了，如果你有问题，欢迎在 Q&A 环节深入探讨。

下个问题，Vercel 关于后端的计划？

目前大部分关注点都聚焦在前端部分，这次讨论了很多想法和很多工程上的进展，为了使前端体验尽可能的快而投入了大量的工作，而要做到这一点的话，我们需要更专注于前端，并为前端提供最佳平台。

目前开发者可以带回他们想要的任何东西，我们设计了我们的系统，方便开发者轻松接入自己的数据库、CMS、支付系统。开发者可以将任何想要的 API 或工具引入我们的系统。我们现在保持很低的配置集成，允许我在大约30秒到1分钟内连接到数据库或者 CMS，具体时间取决于你需要多少步来完成集成。但是你可以很容易进行自己的概念集成，你可以在两分钟内部署一个带数据库的全栈应用程序，这让人非常难以置信。

未来的计划是我们如何将这种体验原生化，我们正在探索一些可能的选择。但本质上，我们希望开发者能更轻松上手我们的平台，对于许多开发者来说，这也意味着开始上手全栈开发，我们也希望在这一点能做得更好。

所以上面的部分就是我的分享，看来控制在25分钟内了，我想确保我有足够的时间来回答大家的问题，我们可以深入探究上面提到过的任何点。现在我们可以敞开聊聊了。

Q&A 环节

1. 谈谈 SWC 和 esbuild ，为什么 Vercel 选择了 SWC

我猜 esbuild 并不是第一个将底层语言或原生代码用于 JavaScript 生态的工具，但它确实产生了最大的影响。我认为 Evan 在发布 esbuild 之后确实重新定义了人们对前端构建速度的期望。我记得 SWC是在 esbuild 之前诞生的，可能早了大概有一年，但我认为这两种工具很大程度上是相互推动的。在我看来，两者最大的不同是 esbuild 被明确设计为不可拓展的，如果你看过 esbuild 的文档，就像 Evan 最初设计的那样，esbuild 想重新定义人们对“快速构建工具”的期望，而不是想搭建一个开发者可以拓展的平台，所以 esbuild 只是在创造一个非常快的构建工具。另一方面，SWC也在尝试做到这一点，并成为一个可拓展的平台，所以这就是为什么 SWC 刚刚推出了 WebAssembly 插件系统，以及我们可见的平台未来的发展方向。

Anne: Cool, 我听说这就是 SWC 作者 Donny 现在为 Vercel 工作的原因吗

Lee: yep 😂

2. Vercel 是如何做应用监控

监控器可能在监控性能，也可能在监控错误或异常，或者在监控日志。我之前谈了一点性能，性能分析可以通过 performance vitals^[4]帮你站在客户或者用户的视角来分析性能状况。对于日志，Vercel 在平台上有实时日志，但也可以将日志发送到任何你想要的地方，可能是你的内部日志记录工具，或者第三方类似 Datadog^[5]的平台，可以更好的聚合和展示日志，很多人都这么做。然后关于错误异常处理，有很多开源工具，比如 Sentry^[6]，当前端出现 bug 时，大家用他们来调试。

3. 怎么说服团队购买 Vercel 服务

我很高兴能有这次交流，能更多的了解你的团队在努力做什么，以及Vercel是否是这个项目或者应用的正确解决方案。通常，当我们与团队评估是否使用 Vercel 之前，会先评估是否使用 Next.js，我们会通过沟通搞明白，我们是通过什么工作的，应用的架构是什么样的，目标是什么。当有团队尝试构建项目的时候，有时候 Vercel 会很适合，但也有时候不太满足需求，他们也许会想做一些不同的事情，我们会与对方团队一起完成这个探讨过程。

4. 如何看待 VR 场景下的前端开发

对我个人来讲，对于 VR 我没有太多经验，作为一种新兴技术，VR 已经度过了从0到1的阶段，大家已经比较熟悉了，但是还没有达到全世界普及的地步。但我认为对新兴技术最好不要持怀疑态度，退一步讲，更好的做法是观察人们怎么使用它，观察下发展趋势。我对VR知道的不多所以不敢轻易下结论，对我来说，我只是看到大家在使用它，我看到人们很享受 VR，这就很棒。

5. 如何看待元宇宙

我对此的看法可能会有一些争议性，比如我认为这很有趣，把时间拉长30年，我敢肯定元宇宙这种东西一定会存在的。但我现在从 Meta 或者 Facebook 中并没有感同身受，因为现在世界上还有很多问题，在进入元宇宙之前先要把这些问题解决掉。所以我不太明白，我对这事保持怀疑。

6. 如何看待 PWA

我认为针对某些类型的应用或者某些场景下，PWA 是个非常好的解决方案，特别地如果你优先考虑离线设计，尝试构建一个真正像移动 app 一样的应用程序，PWA 可能是个好方法。

但也有些不足的地方，因为浏览器的能力还没跟上，就像 PWA 还达不到原生app的体验一样。举个🌰，比如系统推送通知，如果我没记错 Safari 还做不到，但其他基于 chromium 内核的浏览器就可以。

我认为 PWA 和原生 app 的关系是很微妙的，因为原生应用的很多功能都很强大，而我们试图在 web 上进行实现，以及尝试使用 Expo^[7]或 React Native 之类的工具来实现，但对于我来说，web 的最大优势是易于迭代。这实际上很不可思议，因为我写完代码提交上去然后发送到 Vercel 或其他服务，可以在30秒到一分钟或者不管花多长时间，就可以部署到世界各地，对比之下原生引用的构建发布方式就很痛苦，去查查发布流程，你必须通过 Apple 或者 Google 或者其他商店才能上线你的应用，这工作量是很大的。我想这就是为什么一些大厂将实时更新(air updates)构建到原生应用中，只是想用 web 的发布方式发布代码，原生应用的发布方式很棘手。

Anne: 你看好吗，你认为 Apple 会推动 Safari 支持 PWA 吗？

我不知道，我希望对 Safari 持乐观态度，但他们之前没有这种前例，不幸的是看看过去的四五年，Safari 在这方面没有做得更好，我可能对 Safari 的未来有点不看好，希望未来能证明我是错误的，因为我认为有多个浏览器厂商是一件好事，但是，浏览器的实现偏离规范不是件好事，Safari 有一些实现和规范有出入，这让我很头疼，我不希望 Safari 变成下一个 IE 😹

7. 你个人对前端感兴趣的领域有哪些

由于我在 Vercel 工作，并且花费了大量时间去考虑运行性能，结合边缘计算的SSR对我来说是很有兴趣的，特别是涉及到未来的 React 和 React Server Component(RSC)。RSC 非常快，但这背后是 React 团队和 Meta 数年的努力去迭代完善解决问题，他们在五六年里不断的尝试和试错，最终才实现并对外发布 API 。这对我很有吸引力，因为如果你想引入新的 API ，你必须确保这是正确的选择，因为这会被世界上成千上万的应用使用，并且会以年纪，而非以月纪。我们正努力引导 Next.js 社区，了解我们何时会引入新的 API ，API 将会存在很多年，所以我们必须慎重考虑。我们要有这个权衡决策过程：人们升级到这个版本会是什么样子。

8. Next.js 为什么选择一直绑定 webpack 而不考虑结合 bundleless 方案

我觉得这是一个很微妙的话题，这么来说吧，当我们只在 ESM 基础上而不做任何打包的时候，即使使用了现代传输协议，比如 HTTP/2, HTTP/3 ，在处理上百个文件时也无法达到人们想要的效果，特别是当你和打包的方案对比的时候。对于 bundleless 方案，生产环境和本地开发环境也存在区别，因为我认为像 Vite 这样的开发工具，是本地开发时 bundleless ，这与在生产环境使用完全 bundleless ESM 还是有很大区别的。我可能需要写一篇关于这个的文章，对于 bundleless 方案，这里面有一些要切实考虑的有趣的难点。很难说  Next.js 会切换到哪种方式是绝对正确的。

9. 关于 SEO，现在是怎么做的，未来会做 SEO 吗

我想说最重要的一点就是预渲染，无论是静态生成，还是 SSR，或者边缘计算，你在 server 端已经生成 DOM 节点了，这意味着它可以更快的被搜索引擎索引，整体对 SEO 更友好，这并不是一个新东西了。我认为下个阶段，或者他们最近的变化，搜索引擎开始关注真实用户在搜索场景中的性能体验，特别是当与竞争对手进行排名比较的时候。比如有两个搜索引擎，第一个比第二个快10倍，让用户体验更快是很有意义的，特别是现在大多数人都用手机，他们可能是在用流量而非 wifi 在访问，性能对这些用户来说尤为重要。搜索引擎厂商开始重点考虑我们在做的这些性能优化手段，这也是边缘 SSR 的重点改进方向。这是让你的网站更快的最好的方法，而不是让你的处理逻辑离用户更近，在设备终端进行逻辑处理实际上总是不可行的，这有点像 PWA，你需要懂设备的本地存储或者其他一些东西，然后另一个可以离用户更近的环节就是服务器，这实际上就是边缘计算网络所做的，它把你的代码分发到世界各地并且可以运行。

10. 少量需要 SEO 的页面使用 SSR，其他大部分页面 CSR，这种 case 推荐使用Next.js 吗

设想下当开发者使用 Next.js 来构建应用时，他们不会只选一种策略，他们不会说我整个应用都用 SSR，或者说我整个应用都 CSR，现实情况是，他们最终会根据每一个页面的情况去做选择。比如说主页他们希望是完全静态的，这是他们的门面，任何情况下都希望是可用的；再比如 SaaS 应用的个人资料页他们会用 SSR，可能会包含一些身份验证及权限逻辑，即使他们并不需要关心 SEO 。很难为应用制定通用的解决方案，这样做的好处，就是说 Next.js 可以根据需求去采用不同的方式，不仅对于整个应用维度，更是对于页面维度。

11. 使用 Edge SSR 是不是就不能用 NodeJS 的 API 了，只能用标准 Web API

是的，没错。边缘运行时实际上不是 NodeJS ，它实际上是在模拟浏览器，尽可能使用浏览器 API 或者 Web API 。起初这可能是一种限制，因为你无法使用你熟悉的 NodeJS 的东西，通过这个限制，我们实际上能实现我们刚刚谈到的效果，所以你可以把它看做一个特殊的运行时环境，它已经对实现渲染页面最佳性能做了优化。有时候你可能仍然需要 Node 运行时环境，Next.js 一个很酷的地方是这两种都可以，你可以有一个在边缘运行时的页面，另一个是 SSR 或者 Node 运行时的页面，他们可以在一个应用中，而无需使用工具切换。

12. Vercel 有计划开发一个 WebAssembly 运行时引擎吗

这就是用 rust 写的 SWC 为我们提供的功能，因为实际上 Rust 是生成 WASM 代码最好的方式之一，它被设计的与 WASM 有互通性，所以你可以生成 WASM 的二进制文件，你的 Rust 代码基本上就是 SWC 插件如何运作的。边缘运行时环境还支持 WASM 二进制文件，可以获得更好的性能。

13. Next.js 是否有集成 SSR 降级 CSR 方案的计划

是的，现在 Next.js 可以做到这一点，也许它不像人们想象的那样，不太符合直觉，或者不像一个原生的 API ，但基本上可以做到。你可以设置一些阈值，如果你的请求时间超过一个阈值，你可以标记并降级执行不同类型的数据加载。或者我认为你刚说的问题，在遇到报错的场景会更多，如果报错了，我们如何优雅的降级。我认为与这个更相关的是错误边界，在组件级别的页面某部分出现错误，不会影响整个页面。

14. Next.js 对于 React18  Suspense 的实验性兼容目前进展如何

对于多年来一直关注 react 的人来说，Suspense 是一个很有趣的事情，他们知道 Suspense 已经有一段时间了，可能是从 2018 年开始被关注。作为一个外部拓展，并且发展了一段时间，所以我认为一些人对它是什么会有一些了解，或许还有些怀疑。好消息是 React 18 的服务端渲染没有大规模侵入式改动，所以你不知道什么是 Suspense 也是 OK 的，它本质上是一种让你用同步的方式编写异步 React 代码的方法。你可以在 Suspense 边界(Boundary)或者 Suspense 组件中写将要执行的逻辑，他们允许你定义 loading 状态。React 团队一个伟大之处就是把 Suspense 做得很容易使用，在 SSR 时也是，比如 Next.js 中。我很高兴 Suspense 能被广泛普及，这样可以带来更好的用户体验，但这也有很大的学习成本，因为这与传统的 React 应用开发有些不同。

15. Vercel 关于 Suspense 的计划

我们计划使用边缘运行时和 Suspense 重构 vercom.com 。现在的模式有点像部分 SaaS 应用，我们先用 SSR 预渲染一个 loading 态，然后使用 SWR 或者其他数据请求库在客户端请求数据，这种模式已经跑了很多年了，表现还不错。下一次迭代是采用边缘渲染的 SSR，基本上是 RSC 加上 Suspence，这就是我们接下来要采取的方案。

16. 怎么看待 Remix，和 Next.js 对比

Remix 做得比较好的一点是，帮助开发者，如果我们所有东西都使用 nodejs 会是什么样子，他们谈了很多关于 Web API 的东西。我认为这很好，可以帮助开发者查看浏览器状态，可以看到我们现在的浏览器有最好的兼容性和最先进的 Web API，所以这是个很好的提升性能的机会，通过把更多逻辑处理分发到边缘计算中。

因此，Remix 一些未来的规划和 next.js 是不谋而合的，比如边缘运行时，可以帮助 SSR 实现更好的性能。不同的是，我认为 Remix 未来会更关注 Edge，但是离 Node 和 React 越来越远。next.js 的做法是建立在已有的并且会长期存在的东西上的，Edge 是令人兴奋的新技术，我相信未来会有越来越多的人了解使用它，我们会尽力帮助人们去了解适配新技术，next.js 会继续支持 node 很长一段时间，你可以在 node 和 edge 之间自主选择。从商业角度讲，Remix 在尽量远离 React，next.js 恰恰相反，我们喜欢 React，并且计划一直用 React。在我心里，

17. Remix 对 Next.js 的影响

关于 Remix 的影响我想说一件事，就是关于嵌套布局的处理，过去 React Router 做得很好的东西，现在是 Remix 的一部分，并且他们的开发者教育做得很好，这也可以帮 Next.js 的开发者更好的布局。有段时间我们一直在尝试把它引入到我们框架，我们要确保这个和 RSC 的兼容，否则就要重写。我认为现在很接近于公共 RFC ，可以关于改进布局有更多讨论。

18. Rust 和 WASM 在前端的未来

我觉得很容易对 Rust 社区抱有期待，因为它发展的很快，很多人都看好用 Rust 来改进语言和工具。我标榜自己为前端开发者，我喜欢后端但前端才是我的真爱😹，作为一个前端开发者，我看待 Rust 这种工具就是：“OK，我可能不理解它是啥原理，但这玩意很酷，我写了一些小的 Rust 代码，虽然不知道怎么跑起来的，但这很有趣 😎”

Anne: 所以你在学 Rust 了吗 🤣  ？

我有在尝试 😂 ，实际上我学编程语言的过程是从低级到高级的，我在大学学 C ，然后进步了一些去学 Java ，后面是 Python 和 Web 编程，现在有点奇怪，好像是在倒退，我又要回去学低级语言。

Anne: 但你在 Rust 社区很活跃 !

不不不，我有时候会帮助下 SWC ，但我的 Rust 能力很初级 😅

19. 你认为未来 Rust 会在某些场景下替代 Javascript 吗 ？

我不这么认为，你要相信并押注于 Javascript 。在 web 的开荒阶段，很多年以前只有 HTML、CSS 和 Javascript 的时候，Javascript 扮演了非常重要的角色。第一批 web 应用成型，比如像 2002 年的 Gmail ，其创新点就是 Javascript 和 Ajax ，让浏览器不只能渲染 HTML 还能去获取数据。我认为 Javascript 发展很迅猛，并且还会有很多创新，我很难打赌说 Rust 会在某些领域替代它。

Anne: 可以具体聊聊 Rust 和 WASM 吗，或者一些其他语言？

在 SWC 这方面我有做一些功课，并且有计划下次专门聊聊 Rust 生成 WASM 相关的东西。在未来，我们提供的 web 基建将会适配 WASM ，当这些基础架构完成后，用户对于怎么生成 WASM 二进制文件并不需要太关注。到时候也许你可以用 Rust 写 SWC 插件，或者用一些简化的工具来写 WASM，或者直接写原生 web 代码来得到你的 WASM 二进制文件，就像现在用 Edge 方法来使用边缘网络一样，我认为可以做到这个程度。

20. 关于 Serverless ，你认为未来会有让前端更容易上手的 BaaS ，可以更容易开发全栈服务吗，如果有会怎么发展

我认为是的，现在有很多工具可以非常简单的部署后端服务。Next.js 在这方面上做了大量的创新，这意味着一些底层的东西，比如消息队列、数据库等，这些常规来说你需要一个 AWS 账户或类似账户去设置的东西，经过 Next.js 生成器的抽象，这些工作被省去了。基本上 Vercel 是用前端技术栈来开发的，你不需要考虑 AWS ，你只需要使用一个方法，它实际上是调用了 Lamda 方法，但你不必需要 AWS 账户。在很多后端领域也有大量的创新，比如说数据库，过去我一直喜欢用 MySql，后来有了 PostgreSQL ，我个人非常喜欢，它有很多创新，比如通过键值对存储。Serverless Redis 也变得越来越流行，我用过的一个工具叫 Upstash，让部署 Redis 变得非常简单。以上。

21. Vercel 的前端开发体验很好，未来有计划提升后端开发体验吗，比如 BFF 支持云原生计算 ?

这取决于你对 BFF 的定义，这个在很多方面都没有明确的定义，人们对它的看法并不一致。我在 Next.js 里也考虑过 BFF 定义问题，你可以使用 Next.js 中的 API 、路由、或者中间件来为你的前端应用写后端逻辑，我认为最大的问题是，Vercel 是否需要提供更多原生数据存储能力。这个问题正在通过更好的功能集成来解决，我认为在未来，这种底层能力会进一步集成为原生平台的一部分。

22. Vite 和 Webpack 对比

之前我们谈到的 bundleless 和 bundle , 就是 Vite 和 webpack 之间最大的区别。我觉得 Vite 做得很好的一点，和 esbuild 一样，就是刷新了人们对构建工具速度的认知。它促使了 webpack 进行大量的性能优化，webpack 比一年前的版本已经快很多了。但我坚信，在一个很长的时间跨度里，webpack 需要被底层语言重写，或者被替换为一个底层语言写的工具。考虑到现在 webpack 支持了成千上万的应用，重写或者替换不会很快，可能会经历很长的一段时间。但我认为要达到下一个级别的性能体验，需要用 rust 或 go 或者其他底层语言写的工具来支持。

23. 前端技术在飞速发展，如何找到自己的个人定位

是的，这世界上唯一不变的就是变化，在我整个编程生涯中，经常会出现新的不一样的东西，这个问题的核心，是要明白即使有新的技术出现，也并不意味着我要为了学习新技术并马上在公司中采用而放弃一切。我们需要拥抱学习，拥抱新技术新工具来让体验更好，但也并不意味着我们要立刻放弃现在的一切，去使用新的解决方案或工具。这种情况下我取得成功的方式就是学会如何热爱学习，我喜欢研究学习新技术，然后和现有的东西进行对比，我确实会采用一部分新技术，但我不会打算用新技术去重写我们的项目，就好比我会用 rust 替换 next.js 的一部分工具，而不是重写一个框架。

24. 对大多时间用在业务上的前端开发人员有什么建议，如何提升自己，以及未来方向

在我的职业生涯开始时，我的第一份工作内容主要是做闭源工具，当时我没有意识到的是，我为了完成产品学习了很多东西，但我却没有把这些转化为可以对外展示的内容，直到我离开这份工作在面试时发现，我讲的内容没有东西去展示，我才意识到这一点。然后下一段职业生涯，我会把工作中学习的新东西讲出来，我会抓住这个点并分享出来，以此为契机让人们知道我在学习新东西并与其他人分享经验，这样他们也可以学习，因为很多时候开发人员的大部分时间都花费在解决绊倒你的问题上，这些问题可能只有你遇到了，在网上搜不到啥有用的帮助内容，然后你需要花费数周去解决它。这时如果能有一篇文章，或者有人或工具来帮助他们学习，将会节省很多时间。这也是后来我思想上的转变，我作为一个技术人员，从只关注业务逻辑与代码，到学习技术并与世界分享我学到的东西。这也帮我在作为公司的工程师之外建立起个人品牌，但这还有很长的路要走。

25. 欧美程序员的工作强度

我想说工作量和强度可能取决于公司和个人，总的来说，初创公司的工作量一般大于拥有数千人的大厂。然后另一方面我认为是自我管理，取决于你区分工作和生活的能力，但对一些人来说并不好区分，因为他们的工作很有意思，或者很有激情，他们会在工作之外做一些(有关工作的)事情，就比如我会在工作之外阅读技术相关的文章，我也不好说，我不是为了工作去阅读这些文章，我只是喜欢做这件事，所以说工作和生活的界限变得模糊，人们不想觉得生活都只是工作，因为这样会让人心累。所以对我来说，与其说让工作和生活「分离」，不如说是结合，因为对我来说明确的分清工作和生活很难。比方说，我不可能设定下午六点以后就去吃饭然后不再想工作的事情，我的大脑不是计算机，更适合我的是，比如我中午要去看医生或者买点啥东西，然后今晚工作晚了一会是因为中午占用了些时间，我需要这种灵活性，而不是说我工作一整天之后，终于下班了然后再也不想工作上的事，这对我来说很难做到。

Anne: 所以说你并不考虑工作量，更考虑你做了什么？这很棒！

是的，我非常喜欢我的工作，所以上面说的这些对我来说很容易。

26. 怎样的技术深度可以达到前端技术总监的水平

我觉得最大的事情是不仅要管理技术工作，还要领导团队为了一个共同的目标而努力，我需要把目标拆解成更小的部分，同时也需要和其他团队角色去沟通，比如产品经理和设计师。技术 leader 要与其他团队角色配合好，为打造产品共同努力。

27. Vercel 和 React 绑定那么深的话，Rich Harris 在团队里做什么呢😂

是的，我们非常喜欢 React , 但同时我们更聚焦于整个前端领域，我们把 Rich 招过来全职做 Svelte^[8], 我们同样喜欢并看好 Svelte , 但我认为这和 React 并不冲突，而是我全都要。

28. Vercel 的员工遍布世界各地，是如何有效沟通协作的

是的，对于员工分布在全球的公司来说，团队合作是很困难的，因为有时差。所以重要的是尽可能同步工作，这样一旦一个时区的人醒来，他可以简便的使用其他时区同事的工作成果，并且最好无需那个时区的人在线也能解答所遇到的问题。另外尽量让同时区的人一起工作，某些时候不可避免的需要实时沟通交流，或者为了解决某些问题需要实时编程，同时区的人一起工作有助于改善这些问题。

29. 类似 OKR 的目标管理工具是如何制定的

我们在用一个叫 「V2MOM」的工具，一个来自 Salesforce 的工具。我可能记不清它到底包含什么了，好像是 Vision , Measures , Objectives 和其他什么东西，它和 OKR , KPI 一样，都是我们明确定义目标和愿景的方式，并以此来反推我们需要做的工作，OKR 和 KPI 也能达成同样的效果。在我看来，主要是要让团队了解共同目标和前进方向，让团队对目标达成清晰的共识。然后一些事情自然就清晰了，比如达成了什么目标是值得庆祝的。但糟糕的是，人们可能会对共同的目标有不一样的看法，到底要走哪条路？我认为这是现实中会遇到的情况，会有人重复做着和目标不相干的工作。

Anne: 所以是什么工具并不重要，重要的是让大家有共同的为之努力的目标。

是的，每个人用这个工具，这只是我们跟踪实现目标的方式，我认为这是有点用的。

30. Vercel 如何帮助员工成长

即使世界上最好的开发者仍然希望在不同的领域成长和学习，因为虽然他们可能做出了最好的应用程序，但依然会想去尝试某些特定领域或者特定功能。这也是 Vercel 工作的一部分，来帮助这些人取得成功并为他们的成长提供所需的工具，简单打个比方，比如说我现在是 Rust 专家，我 Rust 玩得很溜，但我现在很想学习 HTML 和 CSS ，因为之前一直和底层语言打交道，现在想接触学习一些上层 web 开发的技能，来深入了解前端代码是如何编译构建成对应产物的，Vercel 会去寻求这个领域经验丰富的员工的意见，然后为想学习这个领域的员工提供学习的工具，以及一些进阶指引。

31. Vercel 的招聘倾向什么样的人才，听说 Github 的马赛克墙要很绿才行 😂

Github 活跃度有可能只是他工作的副产品，不是必须的，比如说虽然我的马赛克墙很绿，但大部分我做的东西都是对内的，不会对外公开，可能是在内部一个 isuues 里随手评论了一句，这个也算数的。对于招聘倾向这个问题，我想说首先会考虑经验丰富的开发人员，我们希望他在某一领域有深入的研究，并富有想法，可以是 Rust ，可以是 WASM，或者前后端工程等等，我们希望他能带来一些新观念新想法。对于一个初学者来说，把你放到一个周围都是资深工程师的环境，也会成长得更快一些，因为你正与一堆经验丰富的工程师一起工作。对于一般的招聘诉求，我们比较重视的点是，乐观积极并有一些独特想法，虽然这些想法和公司的方向可能会有出入，但我们会比较重视这些独特的想法。

32. 有计划从 Vue 核心团队招人么

我们也很喜欢 Vue , 并会赞助 Nuxt.js ，我们和他们团队聊过，并谈到赞助的事。我不知道会不会从 Vue 核心团队招人，因为很大程度上取决于他们自己的兴趣，是否希望一直全职做开源工作并保持独立。但我们肯定会从 Vue 社区招人，而且会持续下去。

33. 有在中国的招聘计划吗

是的，我相信随着不断地发展，我们的中国员工也会越来越多，中国的开发者数量在持续的增长，并且有很多了不起的开发者，毫无疑问我们会从中国招聘。

34. DevRel 的日常工作

这是一个好问题，事实上每一天都不固定，我想想举下例子，昨天我写了一篇文章，前天我更新了一一些旧的示例，上周我在为团队制定 RoadMap ，并帮助他们制定当前的工作目标，我们发布了新的 Next.js 版本，所以我们在写文章和制作视频，在社交媒体上回答问题，去告诉大家哪些功能发布了。这些都是日常的 DevRel 和社区工作。

Anne: DevRel 的工作如何衡量呢？

我试图让团队成员都做到最好，有时是和他们一起工作并给予一些帮助指导，有时是让他们独立去做一些东西最后给我一些反馈，这取决于他们个人想法，想如何被管理或者如何成长，这里的核心共同点是我想让他们成为最好的自己。

35. 最后一个问题，有什么推荐的书吗，关于前端工程效率或者跨平台方面的

这是个好问题，我现在脑子里没啥好推荐的书，但我推荐一篇很大的文章，就是 Vercel 的 CEO Guillermo Rauch 在 2013 年左右写的「 7 Principles of Rich Web Applications 」^[9]，这篇文章很有趣，它列举了很多构建 web 应用的框架，然后里面很多原则如今依然有效，技术在演变，框架工具不断兴起衰落，但很多东西是不变的，重要的是让自己理解这些不变的东西，来提供出色的用户体验。你可以去他的博客^[10]看看，那里有不少好东西。

结束

Anne: 非常感谢这次访谈，希望你今天过得愉快，和中国的观众说拜拜吧~

Lee: 我知道你那边已经很晚了，感谢你组织的这次活动，bye bye 👋🏻

感谢李茂同学对访谈实录的整理。

参考资料

[1]

Firecracker: https://firecracker-microvm.github.io/

[2]

Turborepo: https://turborepo.org/

[3]

SWR: https://swr.vercel.app/

[4]

performance vitals: https://web.dev/vitals/

[5]

Datadog: https://www.datadoghq.com/

[6]

Sentry: https://sentry.io/

[7]

Expo: https://expo.dev/

[8]

Svelte: https://svelte.dev/

[9]

「 7 Principles of Rich Web Applications 」: https://rauchg.com/2014/7-principles-of-rich-web-applications

[10]

博客: https://rauchg.com

- END -