Vue作者尤⾬溪：以匠⼈的态度不断打磨完善Vue（图灵访谈）访谈对象：
尤⾬溪，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的场景。vue与react面试题
另外，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做得更好，然后就去研究了。
兴趣也是⼀个很重要的因素，就是说，如果有动⼒想要去做⼀件事情，你就尽可能地把兴趣稍微拔⾼⼀点，定⼀个更⾼⼀点的⽬标，看看能不能把兴趣推进⼀步。技术⼈员肯定会有⾃⼰感兴趣的技术⽅向，⼤部分在某个技术领域做出⼀定成就的⼈，可能都少不了浓厚的兴趣驱动。没有兴趣作为原动⼒的话，很难长久保持⼀种持续学习，持续研究的状态。我也不知道这种兴趣能不能后天培养，但是多探索、多尝试，说不定哪天你就发现了新事物

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。