近日，Evrone 与 Vue.js 的作者尤雨溪进行了一次访谈，了解他对于无后端与全栈方法、以及 Vue.js 适用场景的看法，还有他本人如何在工作与生活之间取得平衡。
记者: 嗨 Evan，很荣幸你能接受我们的访谈。那就先从一个简单的问题开始：您的全职工作岗位是由 Patreon 资助的，大多数人恐怕都没有这样的机会。您能聊聊怎样在工作与生活之间找到平衡，特别是如何避免长期工作带来的倦怠心理吗？
尤雨溪： 虽然我这份工作看似自己说了算，而且大部分时间也都是待在家里，但我每天还是会遵照固定的时间表。庆幸我有孩子，所以只要完成了工作内容，我可以马上陪伴家人。另外，我会在感觉需要的时候给自己安排一段比较长的假期，可能是几个礼拜。这一点对于上班族来说可能比较困难。
记者: 厉害！Vue 3 版本即将发布，在此之后，您是打算休息一阵子，还是马上开始规划 Vite build 系统的下一个版本？
尤雨溪： 我总是存着一大堆工作。在 Vite 方面，目前的目标就是努力提升稳定性——这是一套新系统，用户总会在我当初的设计场景之外使用，所以我得花点时间思考项目的下一步要如何发展。关于 Vue 3.1，我也已经有了一点想法。但休息是肯定的，给自己充电非常重要！
记者: 您是 Google Creative Lab 中的创造力技术专家与艺术史专家。在 Vue 项目当中，您有没有感觉自己的数学、算法以及数据结构功底有点薄弱？在您看来，是不是只有学习过计算机科学理论才能成为程序员？还是说只要能写出平平无奇但却易于理解的代码就可以？
尤雨溪： 坦率地讲，我遇到的这类问题不太多。我个人觉得 Vue 或者说大部分前端框架对于数学和算法专业知识的要求不算太高——至少跟数据库比没那么高。 我觉得自己在算法或者数据结构方面的确不强，虽然提升这方面能够肯定会有所帮助，但想要管理好前端框架项目，最重要的还是了解用户、设计出合理的 API、建立技术社区并长期维护项目承诺。
我觉得编写所谓“平平无奇却易于理解”的代码没什么不好，我不太认同这话里隐藏的那种贬义倾向。 实际上，编写出这样的代码也需要一定经验，而且好代码的核心在于执行效率高，而不是令人拍案称奇的实现思路。 没有接受专业的计算机科学教育当然也能编写软件，不过每一位开发者都应该重视专业教育背景带来的扎实基础。我个人一直采取比较务实的态度——先开始做事，哪怕做得不好。在做的过程中，我们会找到自己的不足之处，并确定下一阶段该从哪些方面提升自己。
记者: 说得好。借助 Nuxt.js 与 JAMstack 等技术方案，开发者得以专注于处理应用程序的前端部分，因为后端部分只需要直接交给 minimal/JS/BaaS 即可。您怎么看待这些“无后端”或者说“全栈”开发方法？
尤雨溪： 我觉得这是一种强调以技术推动产品制造的开发思路。开发者们之所以选择这样的栈，是因为它们正适合自己当前构建的产品类型：后端逻辑相对简单，而前端交互更值得关注。虽然不是什么万灵药，但这类方案确实非常适合特定一部分应用场景。
记者: Vue 已经经历过多次重写。如果时光可以倒流，您会对现在的年轻人们提出怎样的技术建议？
尤雨溪： 请一定认真思考这个问题：怎么才能更好地拆分与解耦内部模块。
记者: 最近几年来，我们发现 JavaScript 与 TypeScript 可以说是齐头并进。您是怎么看待这样的趋势的？是会最终向核心 JavaScript 当中添加某些类型，用 TypeScript 取代 JavaScript，还是做出其他选择？
尤雨溪： 我觉得向 JS 本体中添加类型的可能性不大——因为 JS 是一套由社区委员会负责类型设计的系统，而根据 TC39 委员会的运作方式来看，这事没戏。另外，TypeScript 也不会取代 JS，前者只是 JS 的一个超集。我个人认为，JS 与 TS（带类型的超集）并行发展才是最合理的未来方向，而且这一点在可预见的未来不会改变。
记者: Vue 的用户群体已经超过百万。您认为衡量技术采用率的最佳方法是什么？Stack Overflow 问题热度、GitHub 星评以及其他公共访问指标都不错，但也有不少企业用户需要在隔离网络中工作。他们提不出多少问题，但却实实在在在“使用技术”。我们该怎样把他们纳入到技术普及率的计算中来？
尤雨溪： 对于开源软件来说，核定采用率确实是个老牌难题了，因为用户并没有义务上报自己的使用情况。而作为软件作者，我们也确实没有可靠的采用率跟踪方法。也正因为如此，我才觉得 devtools 扩展用户数量应该作为最可靠的指标，因为它至少覆盖到了全体用户。
记者: 即将发布的 Vue.js 3 中包含大量摇树（Tree Shaking）处理方面的更新。在您看来，为什么摇树处理用了这么久才正式登陆现代框架？是因为里头有什么重大阻碍吗？
尤雨溪： 摇树的工作机制，取决于源代码的特定构造方式——换句话说，只有在项目起步时就在代码编写与 API 设计中考虑到摇树机制，才能保证摇树拥有最好的效果。而现在，我们之所以需要引入大量变更才能实现摇树友好，就是因为直接摇树要么会影响到 API 变更、要么需要进行重大的结构调整（这会带来严重风险）。
记者: Vue 3 当中“基于函数的组件 API”提案遭到了社区成员们的强烈反对。事后来看，您有哪些值得与其他开发者分享的观点？
尤雨溪： 社区成员们之所以反对，是因为他们担心项目管理方会废弃掉 Vue 当前的（2.x 版本）API，其实我们并没有这样的想法。作为项目作者与维护者，我们一般会在日常工作中与热心的早期采用者交互，而他们对于新思路的态度往往比普通用户更开放、更积极，这也导致我们没能对向下兼容性给予应有的重视。用户不喜欢自己熟悉的一切被他人硬生生夺走，我已经深切理解到了这一点。
总而言之，最重要的是了解用户需求。但这事并不简单，有时候我们需要投入大量精力才能获得可靠的需求信息。倾听是必须的，综合各方面诉求才能得出合理的结论。
记者: Vue 的用例范围非常广泛，从小型企业到中型代理机构，再到市值数十亿美元的上市公司皆在其中。LV 公司与美国宇航局也在使用 Vue。有哪些使用 Vue 编写的高复杂度真实前端案例，给您留下了深刻印象？
尤雨溪： 问题在于，大多数“高复杂度真实前端案例”都不开源。我觉得要回答这个问题，大家可以多看看 Vue Devtools 与 Vue CIL UI，虽然它们不属于典型的面向消费者型 Web 应用程序，但无疑都属于由 Vue 编写而成的强大界面成果。
