React 核心研发 Dan Abramov 访谈（下）

React Server Component

主持人：Server Component 的 RFC 草案去年年底发布了，请问 Server Component 的主要目的是什么。

Dan：是的，我们去年 12 月发布了一个 Server Component 的技术预览，但它还处于比较早期的阶段。这应该算是一个还处在研究阶段的特性，与 React 18 相比更偏实验性，也不会包含在 React 18 的特性之中，可能会在其之后才发布。但广义上来说，它与 SSR 并不一样，这也是人们常常混淆的点。最大的区别是，Server Component 只运行在服务器上，它不会被下载下来。你可以把它们想象成某种 API，以往的客户端应用可能会请求 JSON API 来获取数据， Server Component 与之类似，但是 API 换成了在服务器端运行的组件。这样做的优势是你不需要去下载任何代码，可以达成性能上的优化。另一个优势是，因为这些组件运行在服务器端，它们可以直接与数据库、微服务、或者其他任何在这台服务器上的资源进行通信。你不需要把这些资源暴露给客户端，就把它们留在服务器上就好。

主持人：有些用户已经尝试过使用 Server Component 了，所以当我们需要在项目中使用服务器组件的时候，我们需要维护三个组件而不是一个，这带来了额外的复杂性不是吗？

Dan：好的，对于这个问题，我个人其实不太认同这种说法。我不想把这个问题定义为我们需要维护三个组件而非一个。我觉得更准确的说法是，在传统的 React 中，我们只有一种类型的组件；而在 Server Component 中，我们把它们分成了 Server Component，Client Component 和 Shared Component。这个问题就好比你原本只有一部手机，现在你既有手机、又有手表、又有电视，但这并不意味着你要同时去用这三个东西，你只是有了更多的选择。所以对于这个问题而言，不是说你的组件在将来都会以三种形态存在，而是你现在只能用 Client Component 的组件。如果只用 Client Component 能够满足需求的话固然很好，但是当这个 Server Component 这个特性落地的时候，你会有更多的选择来做相同的事。到那个时候，如果你想要使用 React 写博客，想要读取文件系统，这些操作不需要很多复杂的框架也能做到。如果你只是想要使用 PHP 或者 Rails 类似的传统 web 编程风格去做一些数据库的读取操作，Server Component 也能帮你做到。在大多数场景下，我们预期用户们会通过框架来使用 Server Component 功能，比如使用 Next.js。所以幸运的话，你并不需要想太多，也不需要创建什么 API，你只需要在文件名中加上 .server.js，这个文件就可以在服务器端运行，你就可以使用所有 Server Component 的功能了。

主持人：所以我们可以直接通过一些框架来使用这个功能？

Dan：是的，我觉得大部分情况应该都是如此。因为框架就像是整个项目的基础设施一样，会为你连接并组织好项目的各个部分。虽然你也可以去手动配置，但是肯定不如使用框架来的方便。特别是框架还可以实现无配置的启用这些功能，如果你要自己动手，你就得自己把项目的各个部分串联起来。目前我们还没有针对如何使用 Server Component 给出使用的建议，但是鉴于 Next.js 已经支持了 Server Component，如果你想要部署自己的 Server Component，你可以去看看他们是怎么实现的，然后复制他们的做法。又或者你可以直接使用 Next.js 或者其他类似的框架。

React 与 Vue

主持人：人们常把 React 与 Vue 作比较。你个人是如何比较这二者的呢？希望能从设计、性能和使用目的来谈一谈。

Dan：首先我个人没有使用过 Vue，所以我可能做不了特别详细的比较。从技术上来讲，两者可能采取了不同的实现方式吧。Vue 建立在 mutability 的基础上，可以直接去修改 state。这样做带来了一些好处，它写起来更简单，你可以用 mutative style 去写代码，这种写码方式也受到了许多开发者的喜爱。但它也有一些缺陷，比如站在更高的层次来看，有些功能可能是出了名的难以实现，或者根本不可能实现。比如我们正在做的 Transition 功能，又或者是我们想要做的新的动画特性。二者之间的差异太大，就像被一道深深的技术鸿沟隔开了，Vue 在不断探索我们可以用 mutability 做什么，而 React 在不断探索 immutability 能够做到的事。但我们对自己的方向非常有信心，因为我们的背后有近 50 年的函数式编程的研究成果，所以我们明白虽然在落实到实践中可能会遇到一些困难，但是从理论分析的角度我们的方法还是合理的。Vue 和 React 只是在探索两个不同的方向，这件事很好，你只需选择自己喜欢的那个就好。谈到设计的话，我觉得二者最大的区别是 Vue 更倾向于去做一些妥协与折衷，也更关注能不能去解决实际的问题。比如它会提供一些人们呼声很高的功能，包括更加便利的动画，更加便利的条件渲染、组件模板等等。但 React 可能不太一样，我们希望确保 React 提供的每个解决方案都是完全可靠的、可信赖的。所以对于某些仅为了方便而存在的功能，我们抱着宁缺毋滥的态度，宁愿不去实现它们。比如 React 想要重做动画功能，我们最终交付给用户的功能一定比现有方案快上好几倍。我们不会去标准化一些现有的方案，因为我们对如何实现动画这个功能有自己的构想，这个构想会与 React 库深入结合，它会不同于我们现在看到的所有框架。所以说，在 Vue 中，你可以更快地得到自己想要的功能，但是在 React 这里你可能找不到自己想要的功能，只能依赖第三方库来实现，直到我们搞清楚解决问题的方法，知道如何把这个功能做对、做好，我们才会把它集成到 React 中来。这就有点像 Android 和 iOS 在设计理念上的区别。iOS 相对 Android 就经常会少一些功能，比如最初几版 iOS 连复制粘贴的功能都没有，直到出现了通知中心才有了复制粘贴功能。iOS 的特性可能确实会滞后一些，但是当它确定要做某件事的时候，它会把他实现的非常好，我想这也是我们的工作理念。我认为两种思路各有优劣吧。

Flow 与 TypeScript

主持人：Vue 3 已经不再使用 Flow 了，而 React 还在使用，对这一点你怎么看？

Dan：我不觉得这一点很重要啊。这更多还是取决于库本身是如何编写的，我们目前还是需要去做一些静态的类型检查。不过这与用户们使用的 React 类型没有关系，只影响 React 库自身的开发。我们使用 Flow 只是因为我们一开始就用了它，它也能满足我们后续的需求。我们也可以使用 Typescript，但我觉得这不是很关键。这完全不会影响到 React 的用户，因为我们内部的类型和我们暴露出去的类型也有差异。所以这件事不是很重要，我们并不 care。我们当然可以切到 Typescript，但迁移成本较高，不值得我们这样做。

React 的竞争力

主持人：最近有些新出现的前端框架，比如 Svelte 和 Solid-js，他们都不再使用 Virtual-DOM 了，并且声称在性能表现和 bundle 体积上都超越了 React，你怎么看待这一点？

Dan：还是一样，我没有深度地体验过这些框架，所以我不太好下论断。但还是那句话，看上去总有新的东西在出现，但其实并不是这样的。真正能够走通的设计思路其实并不多，React 在走 immutable 这条路，Vue 和 Svelte 在走 mutable 这条路，然后 Svelte 和 Vue 之间在具体实现上可能会有些差异，Solid-js 应该也是这条路上的一个分支。说到 Virtual-DOM，我其实不是很喜欢这个术语。我们尽量不去使用这个词，因为每个人对它都有不同的理解。但我觉得它不是一个与性能有关的东西。我想再重申一遍，我不愿去使用 Virtual-DOM 这个词，因为它是一个非常容易混淆的概念。当我们提到 “Virtual-DOM” 这个词的时候，我们说的其实是一种 UI 在内存中的表现形式。这应该是你期望得到的东西，因为它为开发者提供了更多的选择。比如 Server Component 是运行在服务器端的，但是它需要定义一个数据格式来传递服务器输出的结果，然后在客户端接收。如果你使用 Server Component 做了一个页面过渡的效果，你肯定希望将它与现有的 UI 合并起来。但这一点又跟 PHP 或者 Rails 那种传统的客户端渲染不一样，传统方法渲染的时候，老的页面会消失，然后新的页面逐渐加载，它并不保留任何的状态。如果你有一个搜索框，你输入一些东西，点击搜索跳转到新页面，此时搜索框会被清空。但使用 Server Component 不会发生类似的事情，我们把组件树发回给客户端，我们可以在客户端中将它和现有的 UI 做 diff ，然后渲染有差异的部分，所以搜索框的状态可以被保留下来。该被替换的组件替换了，这一点之所以能够实现，是因为 UI 在内存中有一种中间态的表现形式，它就是人们说到的 Virtual-DOM。这是用来说明 Virtual-DOM 作用的一个例子。另一个例子是，如果我们现在要将一个完整的动画系统集成到 React 中，我应该怎么做。比如我们现在要做一个手势拖动触发的动画，我们肯定不希望每一帧都去做渲染，我们希望只计算几个版本的 UI。假定最左边是 0% 的版本，最右边是 100% 的版本，我们计算好几个类似的关键帧，在拖动的时候就可以利用插值计算出当前 UI 样子。但问题又来了，你怎么去生成那些关键帧呢？你需要一个 UI 在内存中的表现形式，这样你才能在两者之间做插值。这个例子也说明了 Virtual-DOM 的意义，有些特性离开它就没法实现。所以 Virtual-DOM 与性能无关，它的存在只是为了让一些特性变得可行，我们认为这种 UI 在内存中的表现形式还是很重要的。尽管在一些综合性测试里面，我们可能会比其他方案慢 10% 左右，但你应该明白，这并不是一个问题。至少在我们的测试中，当我们分析 Facebook 一些复杂页面渲染的时候。我们亲眼看到的是，React 只花费了 10% 的时间，另外 90% 的时间开销是应用代码导致的。框架能够优化的，可能也就只有 2% 的速度。所以当你去看那些测试的时候，测试代码可能有 1000 行，但是只有一个 component。你可能就只关注到了那 2% 的差异，但它并不能反映应用的实际表现。所以真正影响性能的是整个 app 如何工作，以及我们如何能让用户代码运行的更好。这就是 Concurrent Rendering，Server Component 以及所有新特性存在的意义。我们要去支持更大规模的用户代码，而不是试着去赢下这些基准测试比赛，有些基准测试只有一些不到 10 行的小组件， 它们不值得我们付出时间和努力。

主持人：最近有很多新的库出来了，人们想知道 React 如何做到跟上潮流，保持竞争力。

Dan：是的，我想我已经从某种角度上回答了这个问题。我们正在努力从全局出发，用更加通用的方式去处理那些从单点很难以解决的问题，比如说 data-fetching，代码分割，未来还有动画以及其他的功能，React 在将来能让它们的实现变得更简单。我猜这就是 React 竞争力的来源吧。不过我个人觉得 React 并不需要某些特性来让它“保持”竞争力。比方说当我要用 React 做一些原型的时候，我要去画一些 UI，React 用起来会很自然，很顺手。即便 React 在将来五年没有新的 feature，我也会觉得使用嵌套的函数来表述 UI 是一件很自然的事情。我觉得这种开发方式很合理，我也很喜欢 React 现在的样子，所以我并不觉得 React 要变得更加 “有竞争力” (Dan 用两只手比划了引号)人们才会使用它。但我还是要重申一下，我们现在正在做的很多功能，可以让当前复杂的开发工作简单化，我对它们的存在感到兴奋。

SSR、CSR、NSR、ESR

主持人：Vue 和 React 都在解决网页渲染的问题，但是当前渲染网页有很多种方法，像是 SSR(Server Side Rendering)， CSR(Client Side Rendering)， NSR(Native Side Rendering)， ESR(Edge Side Rendering)，你是怎样描绘未来五年前端的发展的呢？

Dan：这个问题是说，你有很多种不同的方式来运行你的代码，你可以让它在客户端运行、在服务端运行，或者在其他地方运行，问题在于你如何去组织它们。但我觉得这里的大部分工作应该都会由框架来完成，所以再说一遍吧，我还是推荐你去使用框架。像 Next.js 就是一个不错的选择，它能让你对这部分如何实现有一个大体的印象。Next.js 可以通过对 React 现有概念的包装来简化这部分的操作，比如你要使用 Server Component 的话，Next.js 有他自己的 API，getServerSideProps() 或者是类似的方法，你不需要使用 React 原生的方式的去组织项目，Next.js 会通过它自己的 API 将你的项目编排好，让 Server Component 等类似的功能生效。所以我觉得未来... 哦我突然想到，如果你对 Server Component 感兴趣的话，不妨去看一下 Shopify 家最近新出的框架，Hydrogen。他们最近放出了一个 Demo 演示，如果你搜索 「Shopify Hydrogen Demo」 或者类似的关键词就能看到，里面演示了他们是如何使用 Server Component 的，这也是对未来场景的展望吧。如果你只有一个渲染树，比方说你在写页面或是写个博客网站，你只需要去在服务器端的文件系统中读取一些 Markdown 文件，然后将它们渲染到组件的对应位置，最后把渲染好的组件传递给客户端，你只需要考虑组件就 OK 了。至于在哪里执行代码逻辑，这完全是由你自己决定的。有些可能是在构建的时候执行的，有些页面如果你愿意的话也可以在服务器端运行，只有那些与实际交互相关的代码会被下发到客户端，然后在客户端运行。理想情况下，这整个流程还是一个单一的渲染树，你不必去实时关注这部分的差异。你只需要给一些小提示，比如修改一下文件的扩展名，代码就会自动地在最合理的位置去执行。所以你不用想那么多，想自己既要做服务端渲染，还要做客户端渲染，有可能还要其他端的渲染。框架会帮你把这部分搞定的，你只需要使用同一个范式来写代码，它在所有位置都可以生效。

React 与框架

主持人：如何评价「React 更像是一个系统，而非一个框架」这种说法？

Dan：我不会说 React 自身是一个框架，我认为这个说法并不公平。首先我认为 React 只是一个库，因为它并没有去约束你工作的方式，没有去约束你项目的结构，它只是给你提供了工具，让你能够去构建组件。但我确实觉得 React 正在成为一种架构（Architecture），但这和框架又有所区别。因为想要新建一个 React 的框架其实有很多种方式，但是现在 React 对某些技术的实现也有了自己的「观点」，比如应该如何进行 data-fetching，如何去做路由，如何去做服务器端渲染，这些功能应该怎么组合起来。React 只是一种构建 UI 的方式，而不同的框架可以基于这点为用户提供更加上层的能力。

吸引前端开发者特质

主持人：你认为好的科技公司最吸引前端开发者的特质有哪些？能不能简单列举两三个？

Dan：嗯，我想一想。我觉得最重要的一点是「要能够从身边的人身上学到东西」。对我来说，有一个能够无时不刻学习新事物的环境是最重要的。当然这不是说你要去不断学习新的库，不要因为对前端这一领域全貌的不了解就说「前端一直在变化」这种话。我认为事实并不是这样的。正如我说的，大多数新事物都只继承了旧的思想，虽然层出不穷，却只有相同的本质。如果你往更深的地方去探究，你就会发现它们都是同一个东西。但我觉得理想的环境就是，公司 / Team 鼓励你去学习新的知识，团队中有 10 年或者 15 年工作经验的前辈，你可以从他们那里获得收获。组内的高度自治也很不错，你不会被安排去做特定的工作，你可以从任务清单中完成自己想做的工作，这一点也会让工作更有趣。被动的激励自然很重要，但如果你能够发挥主观能动性，作出自己的选择，那也是非常有价值的。我不知道这是否回答了你的问题。

如何学习 React 代码

主持人：很多朋友对你的个人经历感兴趣，你刚加入 Facebook 的时候是如何学习 React 的结构、概念，并慢慢开始贡献代码的呢？

Dan：React 有一个相当复杂的 codebase，里面有很多复杂的上下文导致很难上手。一般来说当有新组员加入的时候，我们会花很多时间陪他们一起看一遍代码。刚开始他们可能会做一些小的 bug 修复或者相对独立的小功能点，来慢慢地熟悉代码。整个流程最关键是要熟悉架构，一旦你对整个项目的架构有了充分的了解，接下来的所有工作就都顺理成章了。有一个对我帮助很大的点，那就是去查看人们的 Issue，并去解决他们。在不同的时间点上，我都会过一遍现在处于 「Open」状态的所有 Issue，看看自己是不是能够解决这些问题，思考一下自己是不是能够理解他们在说什么，如果不懂的话就去学习上下文。我想我个人可能已经看了数千个 Issue 了，如果你想要快速上手项目的话，我认为这是一个非常不错的学习方式。你可以点击查看处于「Open」状态的 Issue，应该差不多有 500 个，你可以从头看，也可以跳转到最后一页从最老的那个开始看。通过看 Issue 你逐渐就能理解当前有哪些问题，慢慢地去理解代码，理解项目的更新历史等等，所以这就是通过 Issue 学习的方法。帮助提出 Issue 的人，在我看来是做贡献的最好方式，实话说我们并不需要人们去贡献那么多的代码，通常 Review 代码也需要花费我们很长时间，而且人们其实很难把功能写对。所以当我们收到社区提交的代码的时候，我们其实并没有从中收获很多。但替我们回答人们的 Issue 确实对我们很有帮助，有时候用户提交了一个 Bug 报告，但实际上是他们自己写的代码有问题。如果社区中有人帮助他们发现了问题，找到了 bug，我们就不用再在这些 Issue 上花费时间了，这也是我最欢迎的贡献方式。

维护 React

主持人：React 有一个非常庞大的 codebase ，请问 React 开发组和社区是如何维护如此复杂的代码仓库的？

Dan：代码仓库确实带来了一些挑战，但是有挑战的原因不是因为代码仓库大，而是因为一些其他的原因。首先你要知道怎么去进行开发，怎样把代码跑起来。举个例子，我们依赖了非常多的自动化测试，大概有数千个测试要跑吧，我觉得数量可能在 5000 个以上。目前我们写的测试代码可能比源代码还要多，我们非常依赖这一点。我们从中学到的一点是：一定要去针对 React 的 public API 写测试脚本。我们之前的做法是对独立的模块进行单元测试，但这对 React 这种项目来说是一个非常糟糕的想法，因为一旦你要重写 React，那些针对老代码的测试用例就没用了。在我们重写 React 的过程中，我们不断地意识到「哦，又有一堆测试代码不能用了，因为之前的代码不存在了」。所以我们把所有的测试用例修改成了仅对 public API 进行测试，来模拟用户的实际行为。测试用例只能用 ReactDom.render() 或者类似的方法，并不能访问内部的 API。在只针对 public API 进行测试的情况下，就算我们替换了原有的文件，测试样例也照样能够跑通，还能顺便测试我们的重写是否是正确的。这算是我们从实践中总结出的经验吧。另一个有趣的点，也可能是比较有争议的一个点，就是我们有很多文件都存在两个版本。如果你看源码的话，你会发现我们有 .old.js 或者 .new.js 这种文件。这些文件基本上是复制粘贴出来的，它们的内容也基本相同。我们用它们来测试一些可能会带来风险更新，对于 Facebook 网站，我们可以同时部署多个版本。我们有时候会将这些实验性的更新写到 .new 文件里面，然后在 Facebook 的实验环境里面进行回归测试，如果测试各项指标没有劣化的话，再将这些更新复制到 .old 文件中去，所以说我们的网站在任何时刻都有两个版本。在实验测试的过程中，其他人也可以去做其他部分的代码提交。这听上去可能比较奇怪，但实际用起来效果还是不错的。

主持人：所以这就是你们在开发中保持 React 代码质量的秘诀吗？

Dan：是的，我觉得是 Facebook 的测试环境真的非常好，我们不仅有针对 React 仓库本身的测试，还有很多针对 Facebook 进行的测试。有时候我们在 React 的开发过程中把功能搞坏了，我们可以在测试环节发现问题。在生产环节中，甚至是生产环节之后，我们都可以部署实验测试，然后去观察哪些指标出现了下降。比如我们去年十月进行了一次重构，那之后我们不得不将手头的工作暂停了两个月，因为我们看到某些指标下降了 1%，我记得好像是网站的评论数之类的少了 1%。我们就要查清楚到底是由性能问题导致的，还是因为 bug 或者其他什么原因。你要知道，其他的框架往往做不到这一点，它们往往需要先发布一个版本，然后可能一年之后才会有人发现里面的 bug，然后上报。但我们不会这样做，我们要确保 React 的高质量，所以我们花费了数月的时间来查这个问题。用二分法不断地分割 commit 提交，不断地去做实验测试，甚至要精确到每个 commit。最终，我们找到了 bug，我们部署的测试环境中确实有一个 bug。当我们将其修复之后各项指标就再次回归正常了，这个结果也给了我们信心。你要知道，在 Facebook 这种体量的公司中，即便只有 1% 的指标劣化，也会影响数百万人。所以如果有大的问题的话会比较容易发现。

阅读 React 源码？

主持人：作为一个使用 React 的前端开发者，我们需要去阅读 React 库的源码吗？如果需要的话，有没有好的阅读代码的方式？

Dan：我觉得没有必要，这可能会是一项相当困难的工作，因为我们没有在任何其他地方提及 React 自身的架构是怎样设计的。如果你上来就开始读代码，你可能会感到非常困惑，不明白为什么这样设计。这可能也是我们将来需要改进的一点，将来到了某个时间点，我们可能会去解释这里面的实现原理。但我觉得如果你只是想玩玩的话，这个过程应该也算不上痛苦。比如我自己就很喜欢做一件事，用 debugger 的步进功能（step-in) 来一行行跑代码，看看代码会跑到哪个函数，运行代码会用到哪些不同的文件。另一件你可以做的事是使用 Chrome Performance Tools，你可以打开 Chrome 的 Performance Tab，点击录制，然后在你的应用中进行一些操作，之后点击停止，你会看到一张火焰图或者火焰表。这个分析结果非常有用，它就像是某种堆栈，你可以看到函数的调用顺序，看到代码中正在发生的事。它常用来测试性能，你可以看到你代码中的哪一部分运行的比较慢，但你也可以用它来做一个当前函数总览，因为上面展示了函数的名称。你可以看到状态变化会引发哪些不同的事情。你可能会发现「哦？这个函数在所有的地方都被调用了，它是做什么的？」。之后你可以点进去，看看里面到底执行了什么。沿着这种性能测试来一步步探索代码我觉得也是一个不错的学习方式，可以了解到 React 在哪部分花了时间，哪些函数是其核心之类的。

保持对 React 热情

主持人：你是如何保持对 React 的热情的？

Dan：我就是很喜欢，不知道为啥，仔细想想的话，可能是因为 React 非常符合我对 UI 代码的看法吧。在进入 Facebook 之前，我就开始使用 React 了，那时候我还在一家小的创业公司。我们当时在开发一个非常复杂的应用，试着将它从 Backbone 迁移到 React。我们迁移不是因为当时 React 是大趋势，而是因为当时用 Backbone 开发一个复杂的 UI 真的非常的困难，相比起来用 React 来实现真的是太简单了。其中心思想就是写一个状态的函数，来表述当前屏幕上应该展示哪些东西。这也是我常常问自己的问题，我的组件应该长什么样子，哪些内容应该展示在屏幕上。这种思想和我的编程思路天然就是契合的。但确实有些东西不太好归纳到这个范式里边，比如 data-fetching 就是一个典型。你真正想要考虑的是屏幕上有哪些内容，但一涉及 data-fethcing，你就要去思考如何与服务端通信、怎么等待服务端返回结果、等待的时候可能还要设置某个状态，这样用户再次发起请求的时候才能忽略掉上次请求的结果。我原本只想考虑哪些东西应该展示在页面上，但这些东西却将问题复杂化了。这也是我们想要为用户提供 data-fetching 能力，比如 Suspense 功能的原因，它可以帮助你减少思考问题的复杂性。我只要考虑想要看到什么，从哪里获取，即便是外部 URL 也不用去考虑时间。我只想要表达目前屏幕上存在哪些东西，之后交由 React 决定如何去展示它们。我觉得让我非常激动的一点是，现在 React 已经能够很好地实现 UI 的组合与嵌套了，但是还有 data-fetching，动画，代码分割，data-asynchronous 这些目前难以实现的东西，我希望这些功能能变得更加简单易用。我希望在五年以后，我们能够用更加简单的方式构建复杂的应用，而这份简单来源于 React 帮助用户处理了这些复杂性。这就是我的想法。

如何像你一样优秀

主持人：如果我想要变得和你一样优秀，有没有什么好的前端学习资料可以推荐的？

Dan：我不确定自己算不算优秀，我其实在很多方面都没有跟上时代的脚步。比如，如果你让我去做一个好看的应用，可能很难去完成。因为我对 CSS 的知识还停留在 2010 年，我对于 CSS Grid 和 Flexbox 也并不是非常了解，我不知道这是不是你希望听到的。但是如果你需要我推荐学习资源的话，我觉得一个很有帮助的点是你可以去挑选一些 UI 的样例，然后从零去实现它们。这个过程中不要去使用 React，也不要去使用其他任何库。比如试着去实现一个带自动补全的输入框，或者是对话框中的一个 tab 之类的，体验一下完成这些操作的复杂度。另一点我很喜欢的是做一些小游戏，这也很有帮助，比如做一个井字棋，或者是贪吃蛇。做游戏会推动你去思考，思考程序如何去设计，思考如何去解决问题，而这一点是你平时写表单、写界面所训练不到的。总结来说，我推荐你做一些体量小，但是有深度的东西，然后从中获得收获吧。

如何度过闲暇时光

主持人：请问工作之余，你是如何度过你的闲暇时光的？

Dan：我工作之余并没有做太多有意义的事。我过去非常爱玩堡垒之夜，我玩的其实并不是很好，但还是玩了很久。我建筑建的很烂，如果有人打我，我就建一堵墙，但通常我都会被吓一跳，然后手忙脚乱地溜走。但我其实也有一阵子没玩了。现在的话一般就听听歌，散散步，做一些业余项目之类的。

justjavascript.com

主持人：你写了一个 「Just Javascript」 的系列文章，我个人也非常喜欢这个系列，已经等不及要看下一期了，想问一下新文章的进展。

Dan：好的，有些朋友们可能还不知道，这其实也是我个人的业余项目，叫做 justjavascript.com。它像是一个 JavaScript 的课程，它现在还是免费的，但是再过几周可能就不免费了。这个课还是很特别的，它不像其他课程一样用传统的方式讲 JavaScript 的知识，它更多是去教你怎么理解代码，课程里面有很多可视化的东西，比如动画呀、图表呀之类的。它也会教你去从零实现一些东西。我想要通过它告诉人们如何去正确地阅读代码，如何正确地理解代码的运作方式。当然我们也在制作一些新的内容。现在我们正在将整个课程打包，然后上传到网站上，完成后这将是一个付费课程，你购买后可以看到里面的内容，所有的课程、绘图与测试问题都会呈现在网站上。我们还不确实是否会有人买这个课程，如果这样做能够赚钱的话，我们可能会更新更多的内容。这个项目之前一直是免费的，已经有一年半的时间了，我们想要看看它是不是一个可行的商业化产品，之后再决定如何去运营它。这个项目几周后就会正式上线，想要支持的朋友可以关注一下。

对中国开发者说点什么

主持人：有没有什么想要对中国开发者们说的话？

Dan：我不知道该说点儿啥。我不确定在中国有多少人在用 React，我只知道 Vue 在中国非常的流行。但我觉得有更多的选择是件好事，我非常感谢那些 React 文档的翻译者们，以及很多 React 库的中国开发者们。我不知道 React 能不能在中国流行起来，这个远在异国的我们可能影响不了。但是如果你对 React 非常感兴趣，你们有机会改变周围的环境，让它流行起来。如果 React 流行起来，以后找工作可能会更容易吧（笑）。我们很高兴看到人们翻译博客文章，传播知识，举办会议，真心地感谢为此付出的每一个人。

主持人：你今后有没有想要在中国的 React 社区中更活跃一点，我们其实很想跟你多多交流。

Dan：当然了，我其实也很想，但是不知道怎么做。正好有你们邀请了我，我感觉这次活动很酷，之后我们可以更经常地交流。

主持人：好的 ，我这边问完了所有观众的提问，非常感谢 Dan 陪我们进行了这次漫长的在线对话。

Dan：感谢你们邀请我。

主持人：感谢，我们下次再见！

Dan：再见！

附录