【第748期】Vue作者尤雨溪：以匠人的态度不断打磨完善Vue

前言

这个周末，前端早读课交给这个帅气的男人，不知道昨天的他在Qcon分享的内容你看了吗？今天来看看@尤雨溪的专访，本文来自@图灵访谈授权。

正文从这开始~

你为何选择从事前端方面的工作？

其实，我本科读的是艺术史，研究生阶段学习Design & Technology，是设计和技术的混合。开始做前端的一个重要原因是，没有人帮我把设计出来的作品放到网站上给别人欣赏。比如说设计一个网站，但是没人帮我把设计出来的网站做出来。所以我只能自己做，做着做着就发现做网站本身也很有趣。

做网站的过程中也涉及怎么写出好的代码，怎样把设计的作品实现出来，后来慢慢发现我对前端更感兴趣，也花费了更多的时间。

前端需要跟用户打交道，可以说，设计方面的背景其实对你的帮助很多。

肯定是有一定帮助的。

又是什么原因促使你萌生了开发Vue的想法？

在谷歌工作的时候，我们要做很多界面的原型，要求快速上手，灵活运用。当时用的一些现有框架，比如angular，太笨重了。个人而言，我更倾向于针对我的用力做一个更轻量化的实现，同时也想做一些实验练练手，研究一下angular到底是如何实现的。所以说，最早Vue是作为一个单纯的实验项目在做。

从2013年7开始，它的增长速度好几次都超出了我自己的期望，我就想能不能再用点力推一把。每次再推一把，它又超出我的预期，慢慢地就变今天这样了。

也有很大一部分原因是，我把Vue当作自己的一个作品，以匠人的态度不断地琢磨完善它。一个版本做出来之后，我会不断地思考打磨，到现在为止我已经重写过两次了。Vue每一次的增长，都会给我更多的动力继续前行。

但是，谷歌主打angular，不会对你有什么限制？

谷歌内部并不会强迫你一定要用什么技术，选择上还是自由的。当时我所在的团队也是比较特殊，creative lab以实验为主，强调速度。对这样的类型项目来说，angular会引入很多不必要的限制。

就像你刚才说的，Vue的代码简约，上手比较快。但是简约跟功能其实是矛盾的两个方面，顾到了简约，就可能限制功能，增加工具的功能性，代码就难免变得繁冗。怎么样做到这种鱼和熊掌的兼得？

英文里面有一个词叫Pragmatism，就是实用主义。在简洁的同时，Vue也强调使用者实现功能的目的。可以说，最早Vue是非常看重这一点的，我们也增加了很多类似于方便性质的API，比如说过滤器。

在早期设计还不是很成熟的时候，我从angular那边借鉴过来的一些功能并没有得到充分地考量。一开始感觉应该有作用，就先放了进来。重新迭代的过程中，我发现它们并没有那么好，也不如看起来那么方便。

随着用力的推广，Vue开始用于一些更长期的项目。这种情况下，一些短期内方便的功能变得难以维护。所以Vue在轻量和功能之间也发生了变化，从一开始的强调速度，简单上手，到后面的注重用户代码的可维护性，避免用户自己掉到自己写出来的陷阱里，一直在不断地转化。最终的目标是找到一个比较良好的平衡点，维持简易上手的良好体验，同时尽可能地避免一时的便易影响长期的可维护性。

眼前利益和长远利益同时兼顾。

对，比如说Vue 1.0、2.0每次变更、废弃API的时候，都会有很多讨论。很多时候，一些用户表示说，这么好用的东西，为什么要拿掉它？拿掉它的原因，其实是，用户用它们写出了一些很匪夷所思的代码。我看了之后就觉得，如果这个东西会导致大家写出这样的代码，可能还是拿掉比较好一些。

国外的情况不太了解，但是国内有一些公司，比如说美团、滴滴、饿了么等这些互联网公司，都开始用Vue开发项目，您觉得国外是怎么样一个情况？

国外的话，Vue的增长趋势分两块。很多中小型企业或者是创业公司会使用Vue开发项目。对他们来说，生产力是一个重要的衡量指标，强调周转效率，快速投入，快速结项目。同时，培训新的开发者加入新项目，达到快速上手的水平也是一个很明显的需求。在这样的需求下，他们对Vue的采用度会非常高。

另外有一些大公司，像日本的Line还有任天堂，英国的一家大型百货连锁公司Sainsburry等也在大规模地使用Vue开发项目。有意思的是，美国主流的大公司，还是比较倾向于用他们自己的硅谷产品。可能源于产业文化的影响，毕竟Google和Facebook的牌子在美国实在是太响了。

Vue的成功给你的生活和技术上带来哪些改变？

最大的影响肯定是，我可以全职开发Vue，也有了时间做2.0的重构。2.0其实是打乱原有的结构，从头开始，重新构建，底层做了很大的改动。能够全职开发Vue，一方面源于网上社区的捐助，一方面来自一些其他的资助，收入上维持跟之前工作时的一样，但自由度的提高让我可以掌控自己的时间，做最想做的事情。

在Meteor工作的时候，有很长一段时间我都很纠结，因为我发现我其实更想做Vue，但是又不得不做公司的事情。虽然也跟公司谈过，却没有找出一个特别靠谱的结合方案，最后我还是决定自己出来干。

有些技术人员被业务忙得晕头转向，而个人能力得不到提高，尤其是技术方面。他们就很苦恼，不知道是屈从于业务，还是发展自己的技能？ 

我觉得自己很幸运，可以做自己特别想做的事情。但是，我希望技术人员不要盲目效仿。Vue是一个特例，很多机遇才让Vue发展到今天的样子。如果没有适当的渠道或者一定的经济支撑的话，我也没有办法全职开发Vue。

最近即将上线的2.0，相对于1.0，在功能和性能上有哪些改进？

总体来说，性能方面提升了将近一倍。我们在技术细节上做了很大改动，整个渲染底层完全换掉了，Virtual DOM的采用打开了很多新的可能，比如说服务端渲染，手动Render Function，结合Weex渲染到原生的客户端。2.0一方面大幅度提升了性能，一方面拓展了更多使用Vue的场景。

另外，2.0在API上也做了更进一步的精简。2.0删掉的API比新增的API要多。之前也说了，Vue在简洁跟多功能之间不断寻求平衡，所以1.0里面的不少“鸡肋”功能——既可以用这个方式实现，又可以用那个方式实现，我们狠狠心就拿掉了。

2016年State of JavaScript的调查显示，Vue的受欢迎程度仅次于React。能否跟大家讲讲React和Vue在定位和内部实现方式上，有哪些异同点？

虽然两者在定位上有一些交集，但差异也是很明显的。Vue的API跟传统web开发者熟悉的模板契合度更高，比如Vue的单文件组件是以模板+JavaScript+CSS的组合模式呈现，它跟web现有的HTML、JavaScript、CSS能够更好地配合。

从使用习惯和思维模式上考虑，对于一个没有任何Vue和React基础的web开发者来说， Vue会更友好，更符合他的思维模式。React对于拥有函数式编程背景的开发者以及一些并不是以web为主要开发平台的开发人员而言，React更容易接受。这并不意味着他们不能接受Vue，Vue和React之间的差异对他们来说就没有web开发者那么明显。可以说，Vue更加注重web开发者的习惯。

实现方式上，Vue跟React的最大区别在于数据的reactivity，就是反应式系统上。Vue提供反应式的数据，当数据改动时，界面就会自动更新，而React里面需要调用方法SetState。我把两者分别称为Push-based和Pull-based。所谓Push-based就是说，改动数据之后，数据本身会把这个改动推送出去，告知渲染系统自动进行渲染。在React里面，它是一个Pull的形式，用户要给系统一个明确的信号说明现在需要重新渲染了，这个系统才会重新渲染。两者并没有绝对的优劣之分，更多的也是思维模式和开发习惯的不同。

两者不是完全互斥的，比如说在React里面，你也可以用一些第三方的库像MobX实现Push-based的系统，同时你也可以在Vue2.0里面，通过一些手段，比如把数据freeze起来，让数据不再具有反应式特点，或者通过手动调用组件更新的方法来做一个pull-based系统。所以两者并没有一个绝对的界限，只是默认的倾向性不同而已。

对于一般的技术人员来讲，掌握某项技术已经是不小的挑战，自己如果可以开发出来一个新工具应该说是一种瞻望的高度。你会给他们一些什么建议用于开发创造新的工具？

我的建议是永远要保持好奇心。很多人可能忙于应付业务，没有在业余时间做任何尝试探索，也就只能停留在这样的一个层面。另外，可能有些东西也是不能强求的，比如说我做Vue的时候，很多时候来自兴趣。我并没有强迫自己一定要怎么样，是自发的一种渴望，我想去把Vue做得更好，然后就去研究了。

兴趣是一个很重要的因素，就是说，如果有动力想要去做一件事情，你就尽可能地把兴趣稍微拔高一点，定一个更高一点的目标，看看能不能把兴趣推进一步。技术人员肯定会有自己感兴趣的技术方向，大部分在某个技术领域做出一定成就的人，可能都少不了浓厚的兴趣驱动。没有兴趣作为原动力的话，很难长久保持一种持续学习，持续研究的状态。我也不知道这种兴趣能不能后天培养，但是多探索、多尝试，说不定哪天你就发现了新事物。

最后，在前端早读课上，除了@尤大大之外，还有更多人的分享，有想了解的可以回复“专访”查看。

关于本文

作者：@尤雨溪

原文：http://dwz.cn/4s3vwD

每天早读，三万同行相伴成长

欢迎投稿：[e-mail]