Vue.js 作者尤雨溪: 框架设计就是不断地舍取
Posted 从零道一
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Vue.js 作者尤雨溪: 框架设计就是不断地舍取相关的知识，希望对你有一定的参考价值。
当时的主流是学金融、数学、经济，然后大家去投行。我当时有很多小伙伴，最惨的去了雷曼兄弟。他实习完拿到了 offer，结果在毕业前雷曼兄弟就垮了，他就特别郁闷。
我上了一些经济的课以后，觉得对这个东西不是特别感兴趣，或者成为“华尔街之狼”并不是我这样的人适合的生活方式。我不是一个特别 driven 的人，对不感兴趣的事情特别没有动力。
我可能比正常人稍微有点个性，但也不算特别有个性。我大部分的人生选择还是处在循规蹈矩的范围里面。我其实是一个比较风险厌恶的人。但我人生中最大的几个决定，反而都是比较反主流的选择。
还是会有压力。因为我家庭不算是特别有钱，我去美国也拿了助学贷款，但是我的父母还是有很高的期望，希望我可以在美国留下来、找个工作。加上本身去美国读书，还是希望毕业之后能至少在美国的行业里积累一些经验。读完书就回去，肯定是很亏的。因为在美国希望学到的，不光是学校里的东西，更多的是进入一个行业里学习。前两年，我在金融、数学、经济这些领域还是做了一些努力，但最终发现我没有办法强迫自己去喜欢这个东西。
当时最大的纠结，是跟随主流做一个大概率能拿到 H1B、但自己不喜欢的事情；还是选一个更符合自己的兴趣，但可能会带来就业上风险的一个选择。当时为了这个，还跟我爸争执了很久。
我现在越来越觉得，创造的冲动是没有办法后天强行弄出来的。我们每个人先天应该都有创造的欲望。当然每个人创造欲望的强烈程度不一样，关键在于，你是否能找到一个趁手的、让自己满意的方式，把创造的欲望表达出来。我其实一直是一个想去创造东西的人。从小到大，我一直在摸索哪一个表达手段是最适合我的。一开始以为是艺术，后来觉得会不会是设计--甚至有一段时间想做平面设计师，但是后来慢慢的发现，写程序给我带来的创造输出的感觉最强烈、最顺畅自然。我在用程序去创造东西的时候，可以很自然地进入 zone，不需要逼自己。我觉得我找到了这样的一个东西，再往这个方向去发展，是自然而然的事情。
如果我要强迫自己做个平面设计师--其实我也做过，但做平面设计的状态跟写程序的状态是不一样的。做平面设计的时候，我也自认有一定天赋，但跟 Google 的那些设计师同事相比，我们的状态完全不一样。
我在做的时候是很纠结的状态，虽然可能他们也会有纠结的时候，但这里面有一些本质的区别，我做设计的时候始终有点水流不畅的感觉。虽然最终有时候也可以做出一些还不错的东西，但是跟我写程序的时候状态完全不一样。写程序的时候，就是我写着突然水管子开了，然后就会有 flow 的感觉。
有个叫中文叫「心流」。如果你在做一件东西的时候，可以进入到心流的状态，就找到了一个跟你的创造欲望契合的表达手段。如果你想要成为一个创造者，你需要找到这样的一个状态。
通过一些技术手段也可以进入这样的状态，但是需要投入大量时间去磨练。如果这个过程一直要依靠意志力来强迫自己，会越来越难。但如果你可以经常进入 flow 的状态，时间投入就不一定带来折磨，甚至反过来给你一种愉悦感，长时间地投入也更简单。
一开始快毕业的时候，我比较倾向于去一个 Creative Agency，严格来说是属于广告行业，但是会偏向于用一些比较尖端的技术手段去做比较非传统商业广告的团队。有一个网站叫做 creativeapplications.net，你看过它上面的案例的话，大概就可以理解我当时感兴趣的业界是一些什么东西。整体上来讲处在在于纯艺术跟商业化广告中间的这样的一个范畴，结合了技术手段去作为他们的表达方式。Creative lab 其实是他们的招聘人员直接来找的我，当时我都还没有开始想申请工作的事情，等于说正在我想要开始找工作的时候，Creative Lab 直接就找上门来了。
我当时做了一个叫 html5 Clear 的应用，Clear 是最早的在 iPhone 上面用手势进行 ToDo 处理的应用，它开启了用左滑右滑这些手势来进行交互的一种新的范式。我看到之后就觉得这个交互好酷，但我也不会写 ios 应用，只会写 javascript。正好那个时候 Google 在推一个叫 Chrome Experiments 的东西, 想要用来颠覆对于浏览器固有的成见。因为之前大家觉得浏览器就只是渲染文档的，大家印象里网页就是网页，就是一堆字，一堆盒子。Chrome experiments 有好多类似于直接在浏览器里做一个 3D 互动的 MV，把你整个网页上所有的东西全变成 物理特性的效果，可以掉下来互相碰撞的各种各样很酷的实验。
我看了这些之后觉得“其实 JavaScript 潜力很大啊”，决定认真学一学 JavaScript，所以就开始自学了。然后又看到 Clear 觉得很酷，想试试看能不能把它的交互在浏览器里面复现出来，就做了这么一个小 demo。做好后 demo 上了 HackerNews 的首页，很多人说没想到浏览器里也可以做出这样的交互来，也引起了一些大公司的注意。
当时 Facebook 还来问我有没有兴趣过去实习，我还特意飞去了 Facebook 总部去面试。结果去面试之后，发现我当时的 JavaScript 还是太菜了。当时我还是野路子的 JavaSript 思维，印象特别深刻的就是面试有一个白板，面试官叫我手写 JavaScript Prototype Inheritence ，我当时就懵了，搞了半天没搞出来，很理所当然那次面试就没过，也没有拿到 Facebook 实习。
不过我当时其实也没觉得是个损失。
当时除了 Facebook 还有一些其他面试的公司。后来 Creative Lab 这边有一个项目叫做 The Five，每年他们会招 5 个刚毕业的新人，组成一个理论上的团队，会有 1 个文案（Copywriter），1 个创意总监(Creative Director)，1 个平面设计师，然后 1 个策略（Strategist），是一个万金油，然后再加 1 个创意技术专家（Creative Technologist），那一届创意技术就是我。这个小团队一起做一个创业项目，如果涉及技术方面就由创意技术专家来负责实现。
当时他们问我有没有兴趣来做这一届的 The Five，对于我来说，这可以说是一个 dream job，完全是百分之百符合我想要找的工作：做的领域是我感兴趣的，做的事情是我擅长的、感兴趣的，Google 也是大公司，可以给我 H1B。
对于职场新人来说，大公司有大公司的好处。所以当时我觉得这实在是运气太好了，感觉最完美的一个 dream job 直接自己跑过来了。
其实现在回想起来的话，可能我当时在找工作这方面，self promotion（自我宣传）还是有些成功，做了个小 demo，并且我当时很多代码都放 Github。现在慢慢的很多程序员也开始意识到，“个人品牌建立”对于找工作是很有帮助的一件事情。
其实当时我也没有很刻意的去往这方面去想，只是觉得作为一个创意技术专家，有一个作品集展示自己是很正常的，艺术家也要有作品集。因为我是从设计转过来的，所以我很自然的会想要去给自己创建一个作品集来展示自己，这比简历更有说服力/大家看你做过什么是最直截了当的，尤其是在创意行业。
可以说是慢慢的发觉，框架设计这种东西到最后都是一些取舍。 比如说最早的设计出来之后，大家老拿 Vue 和 React 去比较。其实我们在设计的时候也会意识到：有一些 React 具有的能力，确实 是 Vue1 没有的，比如灵活的用 JavaScript 表达视图结构，这就是 Virtual DOM 的一个定义。那 Vue 的话只能用模板来表达，而 React 由于它是一个数据结构，所以可以被自由的生成，而不需要一定要用一个模板字符串。整个框架设计到今天，为什么说会 React 有 React 的市场，Vue 有 Vue 的市场，同理还有一些新兴的框架比如 Svelte。它们在数据层、组合逻辑，或者渲染层面上是选择模板还是 Virtual DOM，还是说从中取一个平衡，每一个框架都做了不同的取舍，这些不同的取舍就决定了他们所适合的用例，以及最终它们吸引的人群。
慢慢地，我领悟到了一个东西，就是说在工业上，设计一个面向大量用户的项目时，你没有办法让所有人都满意，更多的还是明确说你的 happy path，还有用户的 happy path 在哪里，然后针对 happy path 去做优化，可以说是 find your niche，然后 play your strength 这样的一种感觉。 但这也是一个相对的，这里面的平衡还是一个很有挑战性的东西，你也不希望你 niche 到最后根本就没人用对吧？
所以你还是要保持相对的灵活性，去尽可能的去兼容更多人的口味，但是你又不希望说你兼容到说为了兼容所有人的口味，最后弄出了一个所有人都不那么喜欢的一个东西。这个度在哪里？就只能通过长时间地，去思考一个一个具体的问题，去琢磨，最后你自然而然的找到你的边界。这是一个很难说你从一开始设计一个框架的时候就能明确的一个东西。
编程语言其实也是一样。你看我们还在不停地发明新的编程语言，你看当年 Ruby 跟 Python 争啊争，现在又是 Rust 跟 Go 争啊争，你永远没有办法用一个语言去满足所有人的口味，因为大家都在用这些语言做不同的事情。
事实上我们现在就是这样的模式，但是我觉得 BDFL（终身仁慈独裁者）模式并不是完全的随心所欲，而在于，有一个人面对争议性的决策有最终拍板的权利，但是他也需要对社区负责任。作为一个 100 多万人的大社区，社区内部意见不一致的时候需要有一个人可以决定如何平衡取舍。如果没有一个决策人，就会陷入无尽的扯皮当中，同时社区也无法进一步发展，有些项目采用所谓的技术指导委员会（Technical Steering Committee）机制 - 一个 6~7 个人的技术委员会投票决定。但是这种模式下的治理成本会很多：要看项目中是否有对项目技术足够了解的人，也要定义委员会成员的选举模式和任期等问题，同时会涉及委员会成员之间意见不合的处理等潜在问题。
一旦变成委员会模式后，效率必然会降低。比如说 JavaScript 这个语言所有的决定都是 TC39 来决定的， 有些新特性可能花几年都没定稿。
而像 Python 的作者 Guido 也是 BDFL，在推进项目的时候也需要面对来自社区的压力。因为 BDFL 在推进自己的想法时，面对社区表现出强烈的反对意见，如果仍然一意孤行的话，就会慢慢失去社区对你的信任。所以要表现出对社区声音的关注和负责的态度，否则如果社区认为你没有将社区利益作为根本考量的话，就会出现分裂。
会有，这个是很现实的问题，现在 Vue 更多是责任。以前写新项目只需要考虑自己，一个下午就可以写出一个很酷的点子。但现在如果要写新功能，我得先写个内部稿让团队内部先评价一下，然后再发布一个 RFC(Request for Comments, 请求意见稿)。但是有些有争议的 RFC 会受到社区里用户的强烈意见，也会在一些细节上纠结很久，就会非常耗费精力。虽然这些意见很大程度上是有价值的，但这些讨论很多时候也会陷入一些细枝末节的僵持中。而且大家在进行技术讨论的时候，你还是会想去说服别人，希望得到大家的肯定，但是并不是所有的时候你都可以真正的说服别人，你也知道在互联网上说服别人是多么难的一个事情。
特别是一些比较有突破性的 RFC，往往也会激发比较有争议的讨论。有的时候你甚至会怀疑，就是说“这个东西，哇，居然有人有这么多意见，我这个东西到底靠不靠谱”？比如说 Vue3 在推出新的 Composition API 的时候，经历了漫长的讨论。但现在我还是觉得这个决定是正确的，顶住压力也还是要做。当有些人不喜欢你的 RFC 的时候，就需要 BDFL 这样一个能够拍板的人来决定如何取舍，想清楚所有的问题。在 RFC 通过之后，实现反而成为了相对简单的事情。
写文档也很花时间，往往一个新功能写文档的时间跟写代码的时间差不多。现在的 Vue 如果要添加一个新功能，中间要耗费的精力和时间比起刚开始做个人项目已经不可同日而语，这也是为什么现在我把它作为我的全职工作。如果我还是像当年一样，认为一个下午就可以出一个新功能，已经不太现实了。
当然要考虑赚钱了哈哈。当时我已经看到有人通过捐助在做开源，所以我当时就开了一个 Patreon，在这个平台上大家可以捐钱给创作者，等于定期众筹。当时我国内有一个朋友，是从 YC 出来、后来搬回国的创业公司的 CTO。他们公司还是很有情怀的，说我们有一个开源的基金，每个月给一个开源项目资助一笔钱。所以他们每个月给我两千还是三千美元，资助了我半年左右。
这笔钱给了我一点点定心丸，说我们可以试试。在离职之前，我已经把 Patreon 开起来了，到离职的时候，差不多一个月有四千美元左右。当时也还没生娃，快生了，加上有点存款，觉得不管怎么样，这点钱过日子还是够的。
当时对我来说，全职做 Vue 并不是永远没有办法再回去的状态。因为 Vue 已经有足够的知名度，即使我全职做了一段时间，发现收入没有办法维持下去，大不了就回大公司。我有信心一定可以再重新找一份大公司的工作，所以养家糊口不是个问题。
做这个选择最核心考虑的是，我全职做 Vue 带来的最大收益，是可以真正把所有的时间都用来做想做的事情--对我来说这是一个巨大的收益。
因为当时我在 Meteor 的状态已经很煎熬了，我觉得我已经不再相信它，再去天天做这个东西，就觉得很没有意义。我强迫自己去做自己不想做的事情的能力很差。
所以我当时觉得，全职做 Vue 可以根本上改变这种状态：从一个每天做不想做的事情，变成做真正想做的事情。即使比当时在 Meteor 赚得少一点，还是可以做到能够基本维持下去。 如果最终连生活的钱都赚不到的话，最坏的情况就回大公司打工就是了。
... (更多内容请参见播客)
- 往期精选 -伯兄投资袁浩瀚：量化不是脱离主观｜ S3E4 极橙齿科塔尔盖：所有最低级的创业错误我都犯了 ｜ 从零道一 S3E3 PingCAP 黄东旭：从 Basic 到数据库 TiDB, 探索开源创业的底层逻辑 | S3E1 欢迎加入从零道一粉丝群，与嘉宾、主持人和其他听友交流互动。
入群步骤：
添加从零道一小助手微信（id: goto_helper)，并备注“粉丝群”
给小助手发送 姓名+公司/学校
我其实一直是一个想去创造东西的人。从小到大，我一直在摸索哪一个表达手段是最适合我的。一开始以为是艺术，后来觉得会不会是设计--甚至有一段时间想做平面设计师，但是后来慢慢的发现，写程序给我带来的创造输出的感觉最强烈、最顺畅自然。我在用程序去创造东西的时候，可以很自然地进入 zone，不需要逼自己。我觉得我找到了这样的一个东西，再往这个方向去发展，是自然而然的事情。
如果我要强迫自己做个平面设计师--其实我也做过，但做平面设计的状态跟写程序的状态是不一样的。做平面设计的时候，我也自认有一定天赋，但跟 Google 的那些设计师同事相比，我们的状态完全不一样。
我在做的时候是很纠结的状态，虽然可能他们也会有纠结的时候，但这里面有一些本质的区别，我做设计的时候始终有点水流不畅的感觉。虽然最终有时候也可以做出一些还不错的东西，但是跟我写程序的时候状态完全不一样。写程序的时候，就是我写着突然水管子开了，然后就会有 flow 的感觉。
有个叫中文叫「心流」。如果你在做一件东西的时候，可以进入到心流的状态，就找到了一个跟你的创造欲望契合的表达手段。如果你想要成为一个创造者，你需要找到这样的一个状态。
通过一些技术手段也可以进入这样的状态，但是需要投入大量时间去磨练。如果这个过程一直要依靠意志力来强迫自己，会越来越难。但如果你可以经常进入 flow 的状态，时间投入就不一定带来折磨，甚至反过来给你一种愉悦感，长时间地投入也更简单。
一开始快毕业的时候，我比较倾向于去一个 Creative Agency，严格来说是属于广告行业，但是会偏向于用一些比较尖端的技术手段去做比较非传统商业广告的团队。有一个网站叫做 creativeapplications.net，你看过它上面的案例的话，大概就可以理解我当时感兴趣的业界是一些什么东西。整体上来讲处在在于纯艺术跟商业化广告中间的这样的一个范畴，结合了技术手段去作为他们的表达方式。Creative lab 其实是他们的招聘人员直接来找的我，当时我都还没有开始想申请工作的事情，等于说正在我想要开始找工作的时候，Creative Lab 直接就找上门来了。
我当时做了一个叫 html5 Clear 的应用，Clear 是最早的在 iPhone 上面用手势进行 ToDo 处理的应用，它开启了用左滑右滑这些手势来进行交互的一种新的范式。我看到之后就觉得这个交互好酷，但我也不会写 ios 应用，只会写 javascript。正好那个时候 Google 在推一个叫 Chrome Experiments 的东西, 想要用来颠覆对于浏览器固有的成见。因为之前大家觉得浏览器就只是渲染文档的，大家印象里网页就是网页，就是一堆字，一堆盒子。Chrome experiments 有好多类似于直接在浏览器里做一个 3D 互动的 MV，把你整个网页上所有的东西全变成 物理特性的效果，可以掉下来互相碰撞的各种各样很酷的实验。
我看了这些之后觉得“其实 JavaScript 潜力很大啊”，决定认真学一学 JavaScript，所以就开始自学了。然后又看到 Clear 觉得很酷，想试试看能不能把它的交互在浏览器里面复现出来，就做了这么一个小 demo。做好后 demo 上了 HackerNews 的首页，很多人说没想到浏览器里也可以做出这样的交互来，也引起了一些大公司的注意。
当时 Facebook 还来问我有没有兴趣过去实习，我还特意飞去了 Facebook 总部去面试。结果去面试之后，发现我当时的 JavaScript 还是太菜了。当时我还是野路子的 JavaSript 思维，印象特别深刻的就是面试有一个白板，面试官叫我手写 JavaScript Prototype Inheritence ，我当时就懵了，搞了半天没搞出来，很理所当然那次面试就没过，也没有拿到 Facebook 实习。
不过我当时其实也没觉得是个损失。
当时除了 Facebook 还有一些其他面试的公司。后来 Creative Lab 这边有一个项目叫做 The Five，每年他们会招 5 个刚毕业的新人，组成一个理论上的团队，会有 1 个文案（Copywriter），1 个创意总监(Creative Director)，1 个平面设计师，然后 1 个策略（Strategist），是一个万金油，然后再加 1 个创意技术专家（Creative Technologist），那一届创意技术就是我。这个小团队一起做一个创业项目，如果涉及技术方面就由创意技术专家来负责实现。
当时他们问我有没有兴趣来做这一届的 The Five，对于我来说，这可以说是一个 dream job，完全是百分之百符合我想要找的工作：做的领域是我感兴趣的，做的事情是我擅长的、感兴趣的，Google 也是大公司，可以给我 H1B。
对于职场新人来说，大公司有大公司的好处。所以当时我觉得这实在是运气太好了，感觉最完美的一个 dream job 直接自己跑过来了。
其实现在回想起来的话，可能我当时在找工作这方面，self promotion（自我宣传）还是有些成功，做了个小 demo，并且我当时很多代码都放 Github。现在慢慢的很多程序员也开始意识到，“个人品牌建立”对于找工作是很有帮助的一件事情。
其实当时我也没有很刻意的去往这方面去想，只是觉得作为一个创意技术专家，有一个作品集展示自己是很正常的，艺术家也要有作品集。因为我是从设计转过来的，所以我很自然的会想要去给自己创建一个作品集来展示自己，这比简历更有说服力/大家看你做过什么是最直截了当的，尤其是在创意行业。
可以说是慢慢的发觉，框架设计这种东西到最后都是一些取舍。 比如说最早的设计出来之后，大家老拿 Vue 和 React 去比较。其实我们在设计的时候也会意识到：有一些 React 具有的能力，确实 是 Vue1 没有的，比如灵活的用 JavaScript 表达视图结构，这就是 Virtual DOM 的一个定义。那 Vue 的话只能用模板来表达，而 React 由于它是一个数据结构，所以可以被自由的生成，而不需要一定要用一个模板字符串。整个框架设计到今天，为什么说会 React 有 React 的市场，Vue 有 Vue 的市场，同理还有一些新兴的框架比如 Svelte。它们在数据层、组合逻辑，或者渲染层面上是选择模板还是 Virtual DOM，还是说从中取一个平衡，每一个框架都做了不同的取舍，这些不同的取舍就决定了他们所适合的用例，以及最终它们吸引的人群。
慢慢地，我领悟到了一个东西，就是说在工业上，设计一个面向大量用户的项目时，你没有办法让所有人都满意，更多的还是明确说你的 happy path，还有用户的 happy path 在哪里，然后针对 happy path 去做优化，可以说是 find your niche，然后 play your strength 这样的一种感觉。 但这也是一个相对的，这里面的平衡还是一个很有挑战性的东西，你也不希望你 niche 到最后根本就没人用对吧？
所以你还是要保持相对的灵活性，去尽可能的去兼容更多人的口味，但是你又不希望说你兼容到说为了兼容所有人的口味，最后弄出了一个所有人都不那么喜欢的一个东西。这个度在哪里？就只能通过长时间地，去思考一个一个具体的问题，去琢磨，最后你自然而然的找到你的边界。这是一个很难说你从一开始设计一个框架的时候就能明确的一个东西。
编程语言其实也是一样。你看我们还在不停地发明新的编程语言，你看当年 Ruby 跟 Python 争啊争，现在又是 Rust 跟 Go 争啊争，你永远没有办法用一个语言去满足所有人的口味，因为大家都在用这些语言做不同的事情。
事实上我们现在就是这样的模式，但是我觉得 BDFL（终身仁慈独裁者）模式并不是完全的随心所欲，而在于，有一个人面对争议性的决策有最终拍板的权利，但是他也需要对社区负责任。作为一个 100 多万人的大社区，社区内部意见不一致的时候需要有一个人可以决定如何平衡取舍。如果没有一个决策人，就会陷入无尽的扯皮当中，同时社区也无法进一步发展，有些项目采用所谓的技术指导委员会（Technical Steering Committee）机制 - 一个 6~7 个人的技术委员会投票决定。但是这种模式下的治理成本会很多：要看项目中是否有对项目技术足够了解的人，也要定义委员会成员的选举模式和任期等问题，同时会涉及委员会成员之间意见不合的处理等潜在问题。
一旦变成委员会模式后，效率必然会降低。比如说 JavaScript 这个语言所有的决定都是 TC39 来决定的， 有些新特性可能花几年都没定稿。
而像 Python 的作者 Guido 也是 BDFL，在推进项目的时候也需要面对来自社区的压力。因为 BDFL 在推进自己的想法时，面对社区表现出强烈的反对意见，如果仍然一意孤行的话，就会慢慢失去社区对你的信任。所以要表现出对社区声音的关注和负责的态度，否则如果社区认为你没有将社区利益作为根本考量的话，就会出现分裂。
会有，这个是很现实的问题，现在 Vue 更多是责任。以前写新项目只需要考虑自己，一个下午就可以写出一个很酷的点子。但现在如果要写新功能，我得先写个内部稿让团队内部先评价一下，然后再发布一个 RFC(Request for Comments, 请求意见稿)。但是有些有争议的 RFC 会受到社区里用户的强烈意见，也会在一些细节上纠结很久，就会非常耗费精力。虽然这些意见很大程度上是有价值的，但这些讨论很多时候也会陷入一些细枝末节的僵持中。而且大家在进行技术讨论的时候，你还是会想去说服别人，希望得到大家的肯定，但是并不是所有的时候你都可以真正的说服别人，你也知道在互联网上说服别人是多么难的一个事情。
特别是一些比较有突破性的 RFC，往往也会激发比较有争议的讨论。有的时候你甚至会怀疑，就是说“这个东西，哇，居然有人有这么多意见，我这个东西到底靠不靠谱”？比如说 Vue3 在推出新的 Composition API 的时候，经历了漫长的讨论。但现在我还是觉得这个决定是正确的，顶住压力也还是要做。当有些人不喜欢你的 RFC 的时候，就需要 BDFL 这样一个能够拍板的人来决定如何取舍，想清楚所有的问题。在 RFC 通过之后，实现反而成为了相对简单的事情。
写文档也很花时间，往往一个新功能写文档的时间跟写代码的时间差不多。现在的 Vue 如果要添加一个新功能，中间要耗费的精力和时间比起刚开始做个人项目已经不可同日而语，这也是为什么现在我把它作为我的全职工作。如果我还是像当年一样，认为一个下午就可以出一个新功能，已经不太现实了。
当然要考虑赚钱了哈哈。当时我已经看到有人通过捐助在做开源，所以我当时就开了一个 Patreon，在这个平台上大家可以捐钱给创作者，等于定期众筹。当时我国内有一个朋友，是从 YC 出来、后来搬回国的创业公司的 CTO。他们公司还是很有情怀的，说我们有一个开源的基金，每个月给一个开源项目资助一笔钱。所以他们每个月给我两千还是三千美元，资助了我半年左右。
这笔钱给了我一点点定心丸，说我们可以试试。在离职之前，我已经把 Patreon 开起来了，到离职的时候，差不多一个月有四千美元左右。当时也还没生娃，快生了，加上有点存款，觉得不管怎么样，这点钱过日子还是够的。
当时对我来说，全职做 Vue 并不是永远没有办法再回去的状态。因为 Vue 已经有足够的知名度，即使我全职做了一段时间，发现收入没有办法维持下去，大不了就回大公司。我有信心一定可以再重新找一份大公司的工作，所以养家糊口不是个问题。
做这个选择最核心考虑的是，我全职做 Vue 带来的最大收益，是可以真正把所有的时间都用来做想做的事情--对我来说这是一个巨大的收益。
因为当时我在 Meteor 的状态已经很煎熬了，我觉得我已经不再相信它，再去天天做这个东西，就觉得很没有意义。我强迫自己去做自己不想做的事情的能力很差。
所以我当时觉得，全职做 Vue 可以根本上改变这种状态：从一个每天做不想做的事情，变成做真正想做的事情。即使比当时在 Meteor 赚得少一点，还是可以做到能够基本维持下去。 如果最终连生活的钱都赚不到的话，最坏的情况就回大公司打工就是了。
... (更多内容请参见播客)
- 往期精选 -伯兄投资袁浩瀚：量化不是脱离主观｜ S3E4 极橙齿科塔尔盖：所有最低级的创业错误我都犯了 ｜ 从零道一 S3E3 PingCAP 黄东旭：从 Basic 到数据库 TiDB, 探索开源创业的底层逻辑 | S3E1 欢迎加入从零道一粉丝群，与嘉宾、主持人和其他听友交流互动。
入群步骤：
添加从零道一小助手微信（id: goto_helper)，并备注“粉丝群”
给小助手发送 姓名+公司/学校
正好那个时候 Google 在推一个叫 Chrome Experiments 的东西, 想要用来颠覆对于浏览器固有的成见。因为之前大家觉得浏览器就只是渲染文档的，大家印象里网页就是网页，就是一堆字，一堆盒子。Chrome experiments 有好多类似于直接在浏览器里做一个 3D 互动的 MV，把你整个网页上所有的东西全变成 物理特性的效果，可以掉下来互相碰撞的各种各样很酷的实验。
我看了这些之后觉得“其实 JavaScript 潜力很大啊”，决定认真学一学 JavaScript，所以就开始自学了。然后又看到 Clear 觉得很酷，想试试看能不能把它的交互在浏览器里面复现出来，就做了这么一个小 demo。做好后 demo 上了 HackerNews 的首页，很多人说没想到浏览器里也可以做出这样的交互来，也引起了一些大公司的注意。
当时 Facebook 还来问我有没有兴趣过去实习，我还特意飞去了 Facebook 总部去面试。结果去面试之后，发现我当时的 JavaScript 还是太菜了。当时我还是野路子的 JavaSript 思维，印象特别深刻的就是面试有一个白板，面试官叫我手写 JavaScript Prototype Inheritence ，我当时就懵了，搞了半天没搞出来，很理所当然那次面试就没过，也没有拿到 Facebook 实习。
不过我当时其实也没觉得是个损失。
当时除了 Facebook 还有一些其他面试的公司。后来 Creative Lab 这边有一个项目叫做 The Five，每年他们会招 5 个刚毕业的新人，组成一个理论上的团队，会有 1 个文案（Copywriter），1 个创意总监(Creative Director)，1 个平面设计师，然后 1 个策略（Strategist），是一个万金油，然后再加 1 个创意技术专家（Creative Technologist），那一届创意技术就是我。这个小团队一起做一个创业项目，如果涉及技术方面就由创意技术专家来负责实现。
当时他们问我有没有兴趣来做这一届的 The Five，对于我来说，这可以说是一个 dream job，完全是百分之百符合我想要找的工作：做的领域是我感兴趣的，做的事情是我擅长的、感兴趣的，Google 也是大公司，可以给我 H1B。
对于职场新人来说，大公司有大公司的好处。所以当时我觉得这实在是运气太好了，感觉最完美的一个 dream job 直接自己跑过来了。
其实现在回想起来的话，可能我当时在找工作这方面，self promotion（自我宣传）还是有些成功，做了个小 demo，并且我当时很多代码都放 Github。现在慢慢的很多程序员也开始意识到，“个人品牌建立”对于找工作是很有帮助的一件事情。
其实当时我也没有很刻意的去往这方面去想，只是觉得作为一个创意技术专家，有一个作品集展示自己是很正常的，艺术家也要有作品集。因为我是从设计转过来的，所以我很自然的会想要去给自己创建一个作品集来展示自己，这比简历更有说服力/大家看你做过什么是最直截了当的，尤其是在创意行业。
可以说是慢慢的发觉，框架设计这种东西到最后都是一些取舍。 比如说最早的设计出来之后，大家老拿 Vue 和 React 去比较。其实我们在设计的时候也会意识到：有一些 React 具有的能力，确实 是 Vue1 没有的，比如灵活的用 JavaScript 表达视图结构，这就是 Virtual DOM 的一个定义。那 Vue 的话只能用模板来表达，而 React 由于它是一个数据结构，所以可以被自由的生成，而不需要一定要用一个模板字符串。整个框架设计到今天，为什么说会 React 有 React 的市场，Vue 有 Vue 的市场，同理还有一些新兴的框架比如 Svelte。它们在数据层、组合逻辑，或者渲染层面上是选择模板还是 Virtual DOM，还是说从中取一个平衡，每一个框架都做了不同的取舍，这些不同的取舍就决定了他们所适合的用例，以及最终它们吸引的人群。
慢慢地，我领悟到了一个东西，就是说在工业上，设计一个面向大量用户的项目时，你没有办法让所有人都满意，更多的还是明确说你的 happy path，还有用户的 happy path 在哪里，然后针对 happy path 去做优化，可以说是 find your niche，然后 play your strength 这样的一种感觉。 但这也是一个相对的，这里面的平衡还是一个很有挑战性的东西，你也不希望你 niche 到最后根本就没人用对吧？
所以你还是要保持相对的灵活性，去尽可能的去兼容更多人的口味，但是你又不希望说你兼容到说为了兼容所有人的口味，最后弄出了一个所有人都不那么喜欢的一个东西。这个度在哪里？就只能通过长时间地，去思考一个一个具体的问题，去琢磨，最后你自然而然的找到你的边界。这是一个很难说你从一开始设计一个框架的时候就能明确的一个东西。
编程语言其实也是一样。你看我们还在不停地发明新的编程语言，你看当年 Ruby 跟 Python 争啊争，现在又是 Rust 跟 Go 争啊争，你永远没有办法用一个语言去满足所有人的口味，因为大家都在用这些语言做不同的事情。
事实上我们现在就是这样的模式，但是我觉得 BDFL（终身仁慈独裁者）模式并不是完全的随心所欲，而在于，有一个人面对争议性的决策有最终拍板的权利，但是他也需要对社区负责任。作为一个 100 多万人的大社区，社区内部意见不一致的时候需要有一个人可以决定如何平衡取舍。如果没有一个决策人，就会陷入无尽的扯皮当中，同时社区也无法进一步发展，有些项目采用所谓的技术指导委员会（Technical Steering Committee）机制 - 一个 6~7 个人的技术委员会投票决定。但是这种模式下的治理成本会很多：要看项目中是否有对项目技术足够了解的人，也要定义委员会成员的选举模式和任期等问题，同时会涉及委员会成员之间意见不合的处理等潜在问题。
一旦变成委员会模式后，效率必然会降低。比如说 JavaScript 这个语言所有的决定都是 TC39 来决定的， 有些新特性可能花几年都没定稿。
而像 Python 的作者 Guido 也是 BDFL，在推进项目的时候也需要面对来自社区的压力。因为 BDFL 在推进自己的想法时，面对社区表现出强烈的反对意见，如果仍然一意孤行的话，就会慢慢失去社区对你的信任。所以要表现出对社区声音的关注和负责的态度，否则如果社区认为你没有将社区利益作为根本考量的话，就会出现分裂。
会有，这个是很现实的问题，现在 Vue 更多是责任。以前写新项目只需要考虑自己，一个下午就可以写出一个很酷的点子。但现在如果要写新功能，我得先写个内部稿让团队内部先评价一下，然后再发布一个 RFC(Request for Comments, 请求意见稿)。但是有些有争议的 RFC 会受到社区里用户的强烈意见，也会在一些细节上纠结很久，就会非常耗费精力。虽然这些意见很大程度上是有价值的，但这些讨论很多时候也会陷入一些细枝末节的僵持中。而且大家在进行技术讨论的时候，你还是会想去说服别人，希望得到大家的肯定，但是并不是所有的时候你都可以真正的说服别人，你也知道在互联网上说服别人是多么难的一个事情。
特别是一些比较有突破性的 RFC，往往也会激发比较有争议的讨论。有的时候你甚至会怀疑，就是说“这个东西，哇，居然有人有这么多意见，我这个东西到底靠不靠谱”？比如说 Vue3 在推出新的 Composition API 的时候，经历了漫长的讨论。但现在我还是觉得这个决定是正确的，顶住压力也还是要做。当有些人不喜欢你的 RFC 的时候，就需要 BDFL 这样一个能够拍板的人来决定如何取舍，想清楚所有的问题。在 RFC 通过之后，实现反而成为了相对简单的事情。
写文档也很花时间，往往一个新功能写文档的时间跟写代码的时间差不多。现在的 Vue 如果要添加一个新功能，中间要耗费的精力和时间比起刚开始做个人项目已经不可同日而语，这也是为什么现在我把它作为我的全职工作。如果我还是像当年一样，认为一个下午就可以出一个新功能，已经不太现实了。
当然要考虑赚钱了哈哈。当时我已经看到有人通过捐助在做开源，所以我当时就开了一个 Patreon，在这个平台上大家可以捐钱给创作者，等于定期众筹。当时我国内有一个朋友，是从 YC 出来、后来搬回国的创业公司的 CTO。他们公司还是很有情怀的，说我们有一个开源的基金，每个月给一个开源项目资助一笔钱。所以他们每个月给我两千还是三千美元，资助了我半年左右。
这笔钱给了我一点点定心丸，说我们可以试试。在离职之前，我已经把 Patreon 开起来了，到离职的时候，差不多一个月有四千美元左右。当时也还没生娃，快生了，加上有点存款，觉得不管怎么样，这点钱过日子还是够的。
当时对我来说，全职做 Vue 并不是永远没有办法再回去的状态。因为 Vue 已经有足够的知名度，即使我全职做了一段时间，发现收入没有办法维持下去，大不了就回大公司。我有信心一定可以再重新找一份大公司的工作，所以养家糊口不是个问题。
做这个选择最核心考虑的是，我全职做 Vue 带来的最大收益，是可以真正把所有的时间都用来做想做的事情--对我来说这是一个巨大的收益。
因为当时我在 Meteor 的状态已经很煎熬了，我觉得我已经不再相信它，再去天天做这个东西，就觉得很没有意义。我强迫自己去做自己不想做的事情的能力很差。
所以我当时觉得，全职做 Vue 可以根本上改变这种状态：从一个每天做不想做的事情，变成做真正想做的事情。即使比当时在 Meteor 赚得少一点，还是可以做到能够基本维持下去。 如果最终连生活的钱都赚不到的话，最坏的情况就回大公司打工就是了。
... (更多内容请参见播客)
- 往期精选 -伯兄投资袁浩瀚：量化不是脱离主观｜ S3E4 极橙齿科塔尔盖：所有最低级的创业错误我都犯了 ｜ 从零道一 S3E3 PingCAP 黄东旭：从 Basic 到数据库 TiDB, 探索开源创业的底层逻辑 | S3E1 欢迎加入从零道一粉丝群，与嘉宾、主持人和其他听友交流互动。
入群步骤：
添加从零道一小助手微信（id: goto_helper)，并备注“粉丝群”
给小助手发送 姓名+公司/学校
作为一个 100 多万人的大社区，社区内部意见不一致的时候需要有一个人可以决定如何平衡取舍。如果没有一个决策人，就会陷入无尽的扯皮当中，同时社区也无法进一步发展，有些项目采用所谓的技术指导委员会（Technical Steering Committee）机制 - 一个 6~7 个人的技术委员会投票决定。但是这种模式下的治理成本会很多：要看项目中是否有对项目技术足够了解的人，也要定义委员会成员的选举模式和任期等问题，同时会涉及委员会成员之间意见不合的处理等潜在问题。
一旦变成委员会模式后，效率必然会降低。比如说 JavaScript 这个语言所有的决定都是 TC39 来决定的， 有些新特性可能花几年都没定稿。
而像 Python 的作者 Guido 也是 BDFL，在推进项目的时候也需要面对来自社区的压力。因为 BDFL 在推进自己的想法时，面对社区表现出强烈的反对意见，如果仍然一意孤行的话，就会慢慢失去社区对你的信任。所以要表现出对社区声音的关注和负责的态度，否则如果社区认为你没有将社区利益作为根本考量的话，就会出现分裂。
会有，这个是很现实的问题，现在 Vue 更多是责任。以前写新项目只需要考虑自己，一个下午就可以写出一个很酷的点子。但现在如果要写新功能，我得先写个内部稿让团队内部先评价一下，然后再发布一个 RFC(Request for Comments, 请求意见稿)。但是有些有争议的 RFC 会受到社区里用户的强烈意见，也会在一些细节上纠结很久，就会非常耗费精力。虽然这些意见很大程度上是有价值的，但这些讨论很多时候也会陷入一些细枝末节的僵持中。而且大家在进行技术讨论的时候，你还是会想去说服别人，希望得到大家的肯定，但是并不是所有的时候你都可以真正的说服别人，你也知道在互联网上说服别人是多么难的一个事情。
特别是一些比较有突破性的 RFC，往往也会激发比较有争议的讨论。有的时候你甚至会怀疑，就是说“这个东西，哇，居然有人有这么多意见，我这个东西到底靠不靠谱”？比如说 Vue3 在推出新的 Composition API 的时候，经历了漫长的讨论。但现在我还是觉得这个决定是正确的，顶住压力也还是要做。当有些人不喜欢你的 RFC 的时候，就需要 BDFL 这样一个能够拍板的人来决定如何取舍，想清楚所有的问题。在 RFC 通过之后，实现反而成为了相对简单的事情。
写文档也很花时间，往往一个新功能写文档的时间跟写代码的时间差不多。现在的 Vue 如果要添加一个新功能，中间要耗费的精力和时间比起刚开始做个人项目已经不可同日而语，这也是为什么现在我把它作为我的全职工作。如果我还是像当年一样，认为一个下午就可以出一个新功能，已经不太现实了。
当然要考虑赚钱了哈哈。当时我已经看到有人通过捐助在做开源，所以我当时就开了一个 Patreon，在这个平台上大家可以捐钱给创作者，等于定期众筹。当时我国内有一个朋友，是从 YC 出来、后来搬回国的创业公司的 CTO。他们公司还是很有情怀的，说我们有一个开源的基金，每个月给一个开源项目资助一笔钱。所以他们每个月给我两千还是三千美元，资助了我半年左右。
这笔钱给了我一点点定心丸，说我们可以试试。在离职之前，我已经把 Patreon 开起来了，到离职的时候，差不多一个月有四千美元左右。当时也还没生娃，快生了，加上有点存款，觉得不管怎么样，这点钱过日子还是够的。
当时对我来说，全职做 Vue 并不是永远没有办法再回去的状态。因为 Vue 已经有足够的知名度，即使我全职做了一段时间，发现收入没有办法维持下去，大不了就回大公司。我有信心一定可以再重新找一份大公司的工作，所以养家糊口不是个问题。
做这个选择最核心考虑的是，我全职做 Vue 带来的最大收益，是可以真正把所有的时间都用来做想做的事情--对我来说这是一个巨大的收益。
因为当时我在 Meteor 的状态已经很煎熬了，我觉得我已经不再相信它，再去天天做这个东西，就觉得很没有意义。我强迫自己去做自己不想做的事情的能力很差。
所以我当时觉得，全职做 Vue 可以根本上改变这种状态：从一个每天做不想做的事情，变成做真正想做的事情。即使比当时在 Meteor 赚得少一点，还是可以做到能够基本维持下去。 如果最终连生活的钱都赚不到的话，最坏的情况就回大公司打工就是了。
... (更多内容请参见播客)
- 往期精选 -伯兄投资袁浩瀚：量化不是脱离主观｜ S3E4 极橙齿科塔尔盖：所有最低级的创业错误我都犯了 ｜ 从零道一 S3E3 PingCAP 黄东旭：从 Basic 到数据库 TiDB, 探索开源创业的底层逻辑 | S3E1 欢迎加入从零道一粉丝群，与嘉宾、主持人和其他听友交流互动。
入群步骤：
添加从零道一小助手微信（id: goto_helper)，并备注“粉丝群”
给小助手发送 姓名+公司/学校
当时我国内有一个朋友，是从 YC 出来、后来搬回国的创业公司的 CTO。他们公司还是很有情怀的，说我们有一个开源的基金，每个月给一个开源项目资助一笔钱。所以他们每个月给我两千还是三千美元，资助了我半年左右。
这笔钱给了我一点点定心丸，说我们可以试试。在离职之前，我已经把 Patreon 开起来了，到离职的时候，差不多一个月有四千美元左右。当时也还没生娃，快生了，加上有点存款，觉得不管怎么样，这点钱过日子还是够的。
当时对我来说，全职做 Vue 并不是永远没有办法再回去的状态。因为 Vue 已经有足够的知名度，即使我全职做了一段时间，发现收入没有办法维持下去，大不了就回大公司。我有信心一定可以再重新找一份大公司的工作，所以养家糊口不是个问题。
做这个选择最核心考虑的是，我全职做 Vue 带来的最大收益，是可以真正把所有的时间都用来做想做的事情--对我来说这是一个巨大的收益。
因为当时我在 Meteor 的状态已经很煎熬了，我觉得我已经不再相信它，再去天天做这个东西，就觉得很没有意义。我强迫自己去做自己不想做的事情的能力很差。
所以我当时觉得，全职做 Vue 可以根本上改变这种状态：从一个每天做不想做的事情，变成做真正想做的事情。即使比当时在 Meteor 赚得少一点，还是可以做到能够基本维持下去。 如果最终连生活的钱都赚不到的话，最坏的情况就回大公司打工就是了。
... (更多内容请参见播客)
- 往期精选 -
欢迎加入从零道一粉丝群，与嘉宾、主持人和其他听友交流互动。
入群步骤：
添加从零道一小助手微信（id: goto_helper)，并备注“粉丝群”
给小助手发送 姓名+公司/学校
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的场景。
另外，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://www.ituring.com.cn/article/273032
以上是关于Vue.js 作者尤雨溪: 框架设计就是不断地舍取的主要内容，如果未能解决你的问题，请参考以下文章
Vue作者尤雨溪：以匠人的态度不断打磨完善Vue （图灵访谈）
尤雨溪 VueConf 演讲：Vue 3.0 的新特性和设计理念