Vue作者尤雨溪:以匠人的态度不断打磨完善Vue
2017-10-15

访谈对象:

尤雨溪,Vue.js 创作者,Vue Technology创始人,致力于Vue的研究开发。

访谈内容:


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

其实,我本科读的是艺术史,研究生阶段学习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,以Vue作为运行时结合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做得更好,然后就去研究了。

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