问了尤雨溪25个问题后，我的很多想法开始变了
5 月 9 日，我在视频号“来广营小盖”连麦了尤雨溪，和他聊了聊 Vue、Vite，以及前端工程师的成长等话题。在这之前，我为了更加全面了解尤大，也看了他所有的知乎回答，并且整理了一篇精华内容，同样放出来供你参考。
下面是连麦内容的文字版本，希望对你有所帮助。
另外，欢迎关注视频号“来广营小盖”，6 月，我会连麦周爱民（前端大神）、乔新亮（前苏宁技术 VP，年薪千万）、万俊峰（go-zero 作者，好未来资深专家）、左耳朵耗子等人，为你交付知识服务，和你一起共同成长。
1、你曾经说过：“Vue 之所以能火，是因为它代表了最新的开发理念（框架层面）。”那么，Vite 呢？它是顺应了什么趋势？更好的解决了什么问题？
尤雨溪：之前，我们已经习惯了基于纯打包的开发方式，但是这种方式在实现过程中会有很多问题。首先，打包就意味着整个应用需要先打包好，浏览器和服务器才能启动，然后才能看到效果；其次，当应用中有很多的依赖时，初始化打包过程就会变得异常缓慢。
基于这些问题，我们在 Vite 上做了一些改进。首先，我们把整个应用拆分成了源代码和依赖，只要版本锁定，依赖里的代码就不会变，也就没有必要做热更新、保留细粒度的模块。如果依赖很大，使用第三方打包器耗时会很久，而采用原生代码写的 JavaScript 打包器，比如 esbuild，就可以快几十倍；其次，对于源代码，则是通过原生 ES modules 来做热更新，确保热更新的速度跟项目大小解耦。
Vite 设计的初衷是改善开发时的反馈速度。这里也要澄清一点，我们的目标是改善体验，而不是干掉 webpack。webpack 存在这么多年，它能够处理很多奇怪的特殊问题，而且 webpack 适用于特别复杂、深度定制的场景。Vite 并不是去解决每一个 webpack 要解决的问题，而是把 95% 用户要面对的问题，做得更简单更快。
2、前段时间，Vite 2.0 刚刚发布，这个新版本中最重要的特性是什么？Vite 2.0 是否足够成熟，可以在生产环境中应用？
尤雨溪：相比于 0.X 版本，Vite 2.0 版本的目标就是保证“生产可用”。
如果要说最重要的特性可能就是没有和 Vue 强绑定，就连 Vue 本身的支持也是通过插件机制实现的。现在很多人使用 Vite 都是直接无缝切换，一些比较小众的框架没有精力自己去做工具链，就会选择 Vite，因为 Vite 可以帮助他们解决 90% 的问题，他们就可以专注于框架本身的东西。
令我自豪的是，Vite 并不是为 Vue 专有，它可以帮助改善前端开发者的开发体验，同时也得到了其它框架作者的认可。
3、你接下来在 Vite 和 Vue 这两个框架之间怎么分配精力？
尤雨溪：其实我很早就意识到这个问题，所以我组建了一个 Vite 的维护团队，团队有差不多四五个人。我们每两周开一次会，对于他们没有办法做决定的事情，大家一起讨论。但是像修复小的问题，或者发布小版本这种事情，我都已经完全交给团队。
我个人比较喜欢以周甚至月为工作时间单位，不太喜欢一天内处理好几个不同的问题。所以我会让团队解决日常的小问题。这样我可以关注一些比较高层面的，或者难度比较大的问题上面。
4、目前 Vite 有没有中长期的规划？
尤雨溪：目前来说，没有规划特别大的新功能。Vite 2.0 发布之后，我们特别开心，因为几乎所有想做的事情都在 2.0 版本完成了，而且 2.0 版本花费的时间比想象中多了很多。所以接下来几个月的重点会放在 Vue 上。
5、对于 Vite 2.0 在企业级层面的应用，你有哪些建议？
尤雨溪：企业级层面最常见的一个需求就是大公司内部要做微前端。在微前端场景中，webpack 5 中的 Module Federation 特性是非常有吸引力的。如果是需要深度定制构建工具的微前端场景，那么 webpack 也会更适合。
当我们的构建部署流程中没有特殊需求，那么 Vite 就可以满足大部分需求。需要注意的是，Vite 默认开发者的最终部署目标是现代浏览器，也就是原生支持 ES Modules，如果想要兼容旧浏览器，就需要使用插件来实现。
6、现在 Flutter 很火，你怎么看 Vue 和 Flutter？
尤雨溪：Flutter 其实跟前端性质不同，因为 Flutter 核心是跨端。Vue 一直以来比较专注的是 Web，可以说我个人重心 90% 还是在 Web 这部分。跨端的需求领域不一样，跨端的框架大家可以看一下 uni-app，做的还是可以的。
Flutter 的问题是它在纯 Web 端不太行，因为它需要一个很重的运行时才能到前端，这样就限制了应用场景，性能优势也没那么明显。但如果你只是用 Flutter 去跨 iOS 和 Android 是没问题的。
7、你怎么看低代码这股浪潮？
尤雨溪：可以假想一个取舍的轴，在轴的一端，是灵活性，就是可以应付任何需求任何场景，再复杂的需求系统也可以满足；另一端是特定业务场景，换言之就是需要写的代码越少越好，比如一个没有任何代码背景知识的产品经理都能拿你的代码做出一个生产环境能用的东西。
但是这两个极端不能同时满足，我觉得现在的工具也是在寻找这两个维度的平衡。比如淘宝搭店铺的框架，做的很简单，每个店小二都能用。但是它的代价是这套系统不能用到其他场景。如果你要做一套既不需要编程，又能应付任何场景的系统，可能导致简单的场景也很难使用，或者一些需求没法满足，最终还是不能做到低代码无代码。
这两天也看到一些比较有意思的探索，知乎上徐飞叔叔发了篇文章，（https://zhuanlan.zhihu.com/p/156887528），大家可以去看看。
1、Vue 使用 JSX，和 Vue 的设计理念是相违背的吗？
尤雨溪：不违背。从 Vue 2 开始，Vue 的模板就是编译成 Virtual DOM 的渲染代码。Vue 2 和 Vue 3 都可以直接将模板编译成渲染函数，而渲染函数是可以手写的。React 中 JSX 也是编译到渲染函数。那既然有手写渲染函数的能力，用 JSX 也是很正常的。JSX 是更像是一个语法上的甜头，而并不是一个功能，为了方便书写习惯而已。
在用 Vue 的时候，我还是推荐用模板，因为性能比较好。Vue 可以在模板做静态分析，编译出来的渲染代码里面有很多优化的数据结构。Vue 的 Virtual DOM 在 diff 的时候是跳跃式的，只是把动态的东西 diff 一下，并不需要走整个树。
2、Vue 3.0 之后，准备加入哪些新特性？
尤雨溪：我们刚刚发布了 Vue 3.1 beta 版本，这个版本的主要内容是从 Vue 2 到 Vue 3 的升级 build。暂时还没有中文文档，但是感兴趣的同学可以去 GitHub 上看一下，Vue 3.1 版本在 vue-next 仓库里多了个叫 vue-compat 的包，如果有应用想要从 2 升级到 3 的可以看一下。
compat 相当于是让 Vue 3 跑在 Vue 2 的行为状态下，兼容 Vue 2 的大部分 API。这样用户就可以一点点把应用从 2 升级到 3。当然，它也有一定的限制，比如像 ElementUI 用了太多 Vue 2 的私有的 API 和行为。但如果是一个对外部依赖比较少的应用，可以直接升级到 Vue 3。
这个兼容 build 里面内容还是比较多的，所以我们把它直接作为 3.1 版本来发布。原来计划在 3.1 发布的内容推到 3.2。3.2 主要计划把 script-setup 功能定稿。当组件里面用 Composition API 的时候，script-setup 可以提升书写体验。3.2 里面还会有一些专项的性能优化。
还会有一些 Web Components 方面的更新。Vue 3 已经确定不支持 IE11 了，所以也打算把对于 custom elements 的支持做进核心里面。主要是方便大家可以用 Vue 的 API 写代码，但是发布的时候可以发布成一个框架无关的组件。同样一套组件，既可以当成真正的 Vue 组件，也可以选择发布成原生的 custom elements，或者原生的 Web Components。
3、什么时候可以看到中文版本的 Vue 3 的文档？
尤雨溪：官方的 Vue3 文档上已经有多语言，包括中文，可能很多同学没注意到。现在我的计划是在 6 月底，把所有的内容，从 NPM 到 GitHub，到默认文档，全部切换到以 Vue 3 为默认。希望一些以前只用过 Vue 2，还没有开始尝试 Vue 3 的用户可以有比较新的学习体验。我们希望新文档不是只告诉用户 Vue 2 和 Vue 3 的区别，而是给用户带来一个新的入门以及学习过程。
4、对于 Vue 源代码阅读方面有什么建议吗？
尤雨溪：我建议大家直接阅读 Vue 3 的源代码，不用再看 Vue 2 了。看 Vue 3 源代码的前提是看得懂 TypeScript，然后可以看看 HCY（霍春阳）写的源码分析。Vue 3 的源码要比 Vue 2 的源码要好学很多。Vue 3 在架构以及模块的耦合关系设计方面比 Vue 2 更好，可以一个模块一个模块看，这样比较容易理解。如果是刚上手，可以从 Reactivity 看起。因为 Reactivity 是整个 Vue 3 里面跟外部没有任何耦合的一个模块。
5、与 2.X 版本相比，Vue 3.0 在客户端渲染和性能更新方面有哪些改进？
尤雨溪：我们想在 Vue 3 里面做到，既保留手写 Virtual DOM，手写渲染函数这种用 JavaScript 表达逻辑的能力，又要有基于模板静态编译获得最好性能的能力。
事实上我们现在做到了，虽然基于模板静态分析生成的是 Virtual DOM 渲染的代码，但是在这个 Virtual DOM 生成的渲染结构中，我们只需要记录几个动态结点。那么当我们在运行时去 diff 的时候，不需要再一层一层的遍历。等于说把一个深度优先的遍历直接拍平成一个数组。数组里面是几个动态的节点，这些动态的节点是以唯一需要再分层的地方，大体上是这样的思路。
我们采用模板的这种语法，它最大的优势是可以很容易地被静态分析。如果用 JSX，或者手写渲染函数的时候，纯 JavaScript 动态性太强，而且没有类型信息，很多东西没有办法做真正的优化。所以在追求极度的灵活性和极度的性能之间总是有一些取舍。
因为 Vue 2 很多库也用了 Virtual DOM，所以我们要继续保留 Virtual DOM 的能力，这意味着我们不可能走没有 Virtual DOM 这种纯编译的路线。虽然一开始是想折衷，但是我们发现，可以既保留这个能力，同时性能也不差。
我觉得 Vue 3 是做了一个比较好的平衡。
6、Vue 会考虑做跨端吗？
尤雨溪：原生跨端这个事情我是不会做的，因为需要的精力太多了。它不是说知道怎么做就够了，而是需要有足够的人力去做这个事情。所以我更倾向于让有资源、有能力、有意向的团队去做这种事情。
7、有人认为 Composition API 虽然很灵活，但新手学起来比较难。你怎么看这个问题？
尤雨溪：很多人的顾虑是一大堆组件全放在一个 setup 函数里会怎么样。首先避免出现大量组件的存在。第二点，假设你已经写出来了，Composition API 虽然是大函数，但跟正常写 JavaScript 没有区别。Composition API 本质就是 JavaScript。
Composition API 的设计目标就是为了方便整理代码，让你自己安排结构，对主观能动性要求更高。本质上要把 Composition API 理解成在写正常的 JavaScript 代码。写 JavaScript 时候怎样把代码写的整洁干净，在写 Composition API 的时候遵循同样的最佳实践即可。要学会开始自己整理，一旦你自己开始整理，可以写出更高质量的代码。
8、如果想学 Vue 3.0 的源代码有没有比较友好一点、由浅到深的路径？
尤雨溪：我觉得首先要想清楚读源码的目的是什么，是想要学写框架，还是觉得用 Vue 就得看源码呢？如果只是单纯用 Vue，使用 Vue 的水平跟看没看过源码的相关性没有那么强。如果是面试问到源码，可能是想考察你对 Vue 一些具体行为的理解程度。
看源码可以帮助你更好地去理解这些行为，但这并不是一个必要条件。从浅到深的基本思路就是，先理解 Vue 的响应式的系统，对应的源码是 Vue 3 的 Reactivity。核心需要理解两个基础的 API，reactive 和 effect。
我在国外办过一天的培训，这里有一个链接，是在培训过程中会写的一些练习的代码（https://codepen.io/collection/DkxpbE）。差不多几百行的代码量，写了一个非常微型的Vue3，可以帮助你理解各个部分怎么整合在一起。
9、你如何看待服务端渲染？未来服务端渲染会给前端生态带来怎样的想象空间？
尤雨溪：前端框架在最开始是纯客户端的，但用户体验，以及对爬虫、搜索引擎、SEO 的优化都不好，所以才有了服务端渲染。服务端渲染的用户体验就好了很多。对于搜索引擎、爬虫来说，看到的也是已经渲染出来的内容，对 SEO 也有很大的帮助，这个是服务端渲染的主要价值所在。
电商对服务端渲染的需求比较高，以及依赖搜索引擎优化的产品也需要服务端渲染。反过来，如果是做一个内部管理平台，那服务端渲染毫无意义。所以是否需要服务端渲染还是要看产品形态。
现在的服务端渲染还存在一些问题。比如 double payload 的问题，一部分内容已经以 HTML 的形式发送到了客户端，但是这里面所包含的一些静态的内容，以及里面用到的动态的数据，又重新以 JavaScript 的形式发送到了前端一次，让框架能够在客户端重新 hydrate。这样就存在信息冗余。
这方面现在有一些新的进展，比如 React Server Components ，把一些静态的内容只在服务端渲染，它的 JavaScript 就不会被发送到客户端。Vue 3 也已经有一部分这样的能力，我们可以直接分析出静态内容，然后把它丢掉。在 Hydrate 的过程中，把静态内容跟 Virtual DOM 的节点再重新对应起来，把这部分信息再收回到 JavaScript 里面。这样避免了同一块静态内容用 HTML 的形式，再用 JavaScript 的形式发送两遍的问题。
Vue 3 的 SSR 整体理念是非常先进的。React Server Components 所做的在 payload 和 hydration 方面的优化，Vue 3 已经在技术上能够实现一部分，并且在 VitePress 里面落地了。我们希望未来的框架能有一些更好的发展，比如直接默认开启这样的优化。
10、Vue 3.0 重构时选择了使用 proxy 代替 getter 来实现对象状态检测，对于开发者来说会有哪些体感的变化？
尤雨溪：会有一些。首先一些常见情况，比如添加一个新属性，或者用方括号去修改数组，或者引用数组里面的东西，现在 Vue 3 都直接支持了，就不需要再用 Vue.set()。而且还支持原生的 map、set、weakmap、weakset 这些数据结构。
但是也有一个区别：proxy 出来的对象跟原对象不是全等的。Vue 2 的行为是，你给我一个对象，我直接把这个对象本身变成了响应式的。而 Vue 3 是你给我一个对象，我给你创造一个响应式的拷贝，这就是 proxy 本身的定义。这个可能会导致一些不同。
在 Vue 2 里面，可以先拿一个普通的对象，把它响应化，继续改变这个原对象也可以触发这个响应式的改变。但是在 Vue3 里面，只有当你去修改这个响应式的 copy 的时候，才会触发响应。所以说用 Vue3 的时候，一个最好的习惯就是不要对原对象存一个引用，直接把它变成一个 Proxy，然后一直只用这个 Proxy 来做事情。大致遵循这样一个原则就行。
1、怎么看待前端的框架演进比后端快太多，层出不穷？是前端更容易造出新的轮子，还是前端的开发基数大，还是其他的原因？
尤雨溪：我觉得这是个伪命题。前端只能用 JavaScript，语言层面的选择少了很多。大部分人造新轮子的努力都是限定在 JavaScript 的前提下。后端可能是只专注于一个语言的技术栈，但是后端不是只有 Java 一个语言。之前出了 Ruby、Python，现在又有人用 Rust、Go 等等新语言，每一个语言下面还有各种各样的框架。所以后端框架的各种实现，比前端数量多，也复杂得多。
【编辑推荐：有这个困惑的同学还是去看看这篇总结吧。】
2、你怎么看 uni-app？
尤雨溪：uni-app 在技术上是很值得认可的成就。跨端需要投入的技术精力很大。从开发体验来说 uni-app 有一些可以改进的地方，我现在也在和他们合作，把 uni-app 更新到 Vue3 。希望借此机会可以给他提一些开发体验上的改进意见。
3、国内有人说 Vue 出得太快学不动了，从你的全球化视野来看，其他国家地区会有这样的看法吗？你怎么看国内前端的环境？
尤雨溪：首先，觉得前端变化太快，新东西太多，这个看法是全世界都有的。但是 Vue 的节奏这两年算是非常慢的了。我们出一个新东西，用户一般两三天就会学了，但是我们要做半年。只要我们能写得出来，你就肯定能学会，这个是没有疑问的。当然我也知道大家大部分时候是单纯在玩梗而已。想要靠技术吃饭，持续学习是一个必须的条件。
4、微前端很火也是，你有接触过吗？
尤雨溪：我觉得微前端是一个业务场景催生出来的需求，它更多的是一种团队协作需求。我日常工作中没有这样的需求，所以对它也没有特别强烈的感受。英文里有一个词叫 buzzword，就是大家都在讨论这个东西，那我们也得上，我们也得学。但我的看法是看自己的需求来定。比如我们现在有一些旧应用要跟新应用并成一个大的应用下面，但这种场景不是每个人都能遇到，遇到了可以用微前端的理念去解决。
5、国内很多人在前端需要写业务代码。大家比较焦虑，有很多需要学习的东西。
尤雨溪：这个现象肯定跟整体环境的“卷”脱不开关系。但是从另一个角度来讲，也是市场需求决定的。整个市场对于非纯业务的前端职位的需求量确实没有那么高。从某种程度上来讲，绝大部分的应用都是趋于典型的。
在大厂里面，会有各种特殊的业务需求，一些历史遗留问题，一些更有挑战性的技术问题。在中小型公司，可能 90% 的情况下都是解决差不多的问题，那自然岗位需求也变得同质化。所以从个人的角度来讲，还是要有不同的竞争力。
如果想要跳出这种单纯做业务的状态，就得去寻找在当前的业务场景下，是否有更有意义、更有价值的这些问题去解决，或者说有没有什么机会可以让团队的效率更高，或者说业务上有什么痛点可以用我的技术去解决。前端在整个产品里面扮演着一个怎样的角色，有没有什么机会在前端这个环节给整个链路去创造一些价值。
如果能找到这样的东西，如何跟我擅长的技术去结合起来，或者说我觉得这个东西很值得解决，我通过怎样的学习可以让自己能够去解决这个问题。找到更高、更明确的目标，这样在学习的时候会更有指向性。还有另一种选择，如果你发现你所在的岗位完全没有任何可以用前端去创造改变的可能性，那么可以跳个槽，提升一下技术能力，进大厂找找机会。
6、你曾经在知乎上提到前端发展的几个层次，表现层，应用实现层，业务架构层，基础设施层？
尤雨溪：前端发展有好几个层，但是只有在一些大公司有专门的前端技术团队的情况下，才有这样的职位。在一些中小型的公司，前端就是一个纯粹的职能部门。尤其当公司的核心产品业务并不是技术为主的时候，这种情况下前端就是完成任务的角色。
7、你现在有看到什么新的前端的趋势吗？
尤雨溪：一个比较重要的趋势就是工具链，利用原生语言写的工具链来提升开发的体验效能。另外一个大趋势是在整体的生产力提升挖掘。过去几年，大家还主要围绕着前后端分离这样的模式。慢慢的我们发现，如果想要进一步挖掘生产力提升，还是得往全栈这个方向走。
比如 meteor，meteor 当时第一个走 JavaScript 全栈路线。新出来的 Remix 也是全栈，前后打通，尽可能的在框架层面把前后端沟通的 Overhead 去掉。再进一步挖掘的，干脆把数据层也直接拉进来，比如说像 Blitz.js 这种。这个就很接近当年 meteor 的形态了。现在我们兜兜转转绕了一圈，大家又开始重新往这个方向去挖掘了。
其次，在前后端数据完全打通的情况下，把整个链路类型化，也是一个值得挖掘的方向。工业聚（他的个人ID）在这方面也有一些探索。他开发的 Farrow.js 是一个在后端做了一些类型探索的框架。
整体而言，这是我看到的两个比较大的趋势：全栈的逆袭，还有原生语言所写的 JavaScript 工具。
8、你认为程序员从幼稚到成熟的过程是什么？知乎上我看到你有关注这个话题。
尤雨溪：我觉得成熟的过程就是慢慢地认识到没有“银弹”。很多年轻一点的程序员，甚至是很多年资很久的程序员，往往对一些问题有着非常绝对的论断。比如说“某某技术就是垃圾”，或者说“某某技术就是不行”，或者说“这个问题就该这么解决”。
凡是这么说话的程序员，我认为都还没过那个阶段。当你真的面对过真实的业务场景，解决过真实的问题，或者说长时间维护过一个烂代码，你就会明白，纯理论可以做得很好，很漂亮，很完美，但一旦到落地到工程中，到处都是取舍和平衡。
工程本质上就是戴着镣铐跳舞，怎么样在有限的资源，在没有办法改变的外部环境下，用最有效率，最合适的方式去解决问题。很多程序员在真正的经历这样的问题之前，他会觉得一切都可以用完美的技术去解决，一切都可以做到理论最优。
如果你是个工程师，你却不承认现实中已经在工程落地的解决方案，你说这个东西为什么不这么做？他肯定是在落地的过程中遇到了一些你没有看到的，需要做取舍的问题。这个时候更需要思考，为什么会做这样的取舍，而不是说这么简单的问题为什么他们没有看出来。
你好，我是极客时间的总编辑，接下来的一年时间，我希望能够用视频号直播的方式，为你提供知识服务。我每次直播，大概会持续 1-2 个小时，我知道，每个同学的时间都很宝贵，所以我对自己的要求也很高。我希望能够请到行业里的牛人，问出来好的问题，让你有收获。
我希望我每次的直播，都能够给你交付一个解决方案。所以直播间，有任何的问题，不要害羞，随时 call 我，我尽力帮你解决。
当然，咱们这个直播，我也想的很清楚，我不会和你讲一个个具体的技术，讲很多的技术细节，这个不现实。我希望的是在茶余饭后，你开着直播，觉得这哥们说的挺有意思，然后在这个基础上，我希望能帮你看到行业的方向，行业的趋势，大牛的做事逻辑，大牛的成事心法。我一直觉得，这些东西，比具体的技术重要多了。
每周三晚上 8 点，和我一起，和牛人聊天，向他们学习。
【2021 北京智源大会】正在火爆进行中，图灵奖获得者与来自全球的人工智能顶尖大牛齐聚一堂，与企业家和开发者们一同探讨人工智能的科研理论、商业实践和社会伦理未来方向，分享他们的洞见！超大规模智能模型系统——智源“悟道 2.0”也将在大会现场公布！6 月 1 日 -6 月 3 日北京中关村国家自主创新示范区会议中心，就等你了！
扫描下方图片二维码或者点击底部【阅读原文】报名参会。
点个在看少个 bug👇