Vue的理念问题

今天看到 CNodeJS 上一个讨论 Vue 的帖子，语气比较偏颇，说实话我看完以后很不爽，但觉得在帖子下面跟人辩没什么意义，有些话可能还是花点篇幅说清楚好一些。

1. 所谓推广

似乎有人觉得 Vue 被『过度推广』了。其实我不是很明白这个印象是怎么来的。我所做的『涉嫌推广』的事情，无非是以下这些：

• 在知乎回答问题。如果问题跟 Vue 无关我甚至尽量不提 Vue，如果问题本来就跟 Vue 有关那我也没办法&＃8230; 至于自己提问自己答这种事情我是绝对不会做的。
• 偶尔发发关于 Vue 的微博。其实我的微博一般是个人内容，只有有新功能或者版本的时候才会涉及 Vue。
• 在开源会议演讲 / 做线上分享。全部都是受邀。事实上我谢绝的都有一大堆。
• 国外方面，有重大发布的时候会发个 HackerNews，其他时候主要也就是在官方 Twitter 账号发推。
• 从开始到现在，没有花过一分钱在所谓的『推广』上。

至于社区自发写的 Vue 的文章，媒体自发要发的关于 Vue 的内容，这就跟我没有什么关系了。如果你觉得这是『过度推广』的话，大概只是因为你不喜欢的东西火了吧。这我也没办法，你不服可以憋着。

2. 所谓借鉴

引用下帖子里的话：

ember有个cli可以一键生成项目，vue就出了个vue-cli。

react出了jsx之后，vue也添加了对jsx的支持，react的vdom号称性能牛逼，vue2.0就也实现了vdom。

react有reflux、redux实现单项数据流，vue就也实现了个vuex。

vue的出现就是对angular 1.x的模仿，无论是模版还是双向绑定。

vue总是在借鉴、模仿别人，将别人的思想重新实现一遍。

我们一条一条看：

• CLI 的问题，服务端框架像 rails, laravel 都有 cli，这又不是什么新想法。所以按这逻辑，ember 是抄了 rails&＃8230; 现在 React 也有 create-react-app，Angular 2 也有 cli，大家都抄了&＃8230; 抄了谁？说到底是因为 cli 解决了一个框架所共有的生产力问题，所以大家都提供而已，就像 SPA 路由、编程语言的 repl 一样&＃8230;
• 再说 vdom。React 的 vdom 其实性能不怎么样。Vue 2.0 引入 vdom 的主要原因是 vdom 把渲染过程抽象化了，从而使得组件的抽象能力也得到提升，并且可以适配 DOM 以外的渲染目标。这一点是借鉴 React 毫无争议，因为我认为 vdom 确实是个好思想。但要分清楚的是 Vue 引入 vdom 不是因为『react 有所以我们也要有』，而是因为它确实有技术上的优越性。社区里基于 vdom 思想造的轮子海了去了，而 ng2 的渲染抽象层和 Ember Glimmer 2 的模板 -> opcode 编译也跟 vdom 有很多思想上的相似性。
• 再说 JSX &＃8211; 在 vdom 的前提下，支持 JSX 是个很自然的事情（babel 插件）。Again，引入的原因不是因为『react 有所以我们也要有』，而是因为有用户提出了需求。难道我应该对用户说『因为 react 有所以我们不能有？』
• Reflux 和 Redux 都是 Flux 衍生出来的，它们是不是都抄了 Flux？Flux 是不是抄了 Martin Fowler 的 Event Sourcing? Redux 还抄了 Elm Architecture？Elm 又抄了 Haskell 和 Conal Elliot 的 FRP? 说起来 Elm 也用了 vdom 呢&＃8230;
• 再说模板。Angular 1 的各种绑定难道不是抄了 WPF？哎呀这个双花括号抄了 Mustache，过滤器抄了 jinja&＃8230;

好了，我想你也明白我想说什么：现代软件工程哪个项目不是站在无数前人的肩膀上？互相借鉴、启发、传承本来就是开源软件的常态。比如说 Flux 衍生出来的一堆状态管理方案，都是对数据流理念的不同实现，难道仅仅因为理念是相似的，不同的实现就没有意义了？Flux 的提出开启了前端对于状态管理的重视，在那之后状态管理方案就跟前文所述的路由/CLI 等一样成为一个标配性质的东西了，大家针对各自框架的特点，各有各的实现，互相之间谁 inspire 了谁都是大大方方地写在 README 或者文档里的，再正常不过。

再者，你日常用到的算法里面，有几个是你自己发明的？如果你是个发 paper 的大神，那我也认了。但你如果是在解决实际的工程问题，在『借鉴』这个问题上纠结是不是有些找错重点了？Vue 添加的每个新功能，考虑的不是别人有没有，而是能不能对 Vue 的用户有用，这才是我关心的。

3. 所谓理念

vue总是在借鉴、模仿别人，将别人的思想重新实现一遍。

其它框架基本没有受到过vue的反哺

据我所知，Vue 是第一个，也可能依然是唯一一个提供支持混合预处理器的、作为 ES 模块编译的单文件组件的框架。唯一有类似功能的 Riot 是在 vueify 出现之后才开始支持预编译和预处理器的，并且并不和 ES 模块契合。Polymer 1.0 的时候就说要支持 css 预处理器结果到现在也没做（即使是编译 ES2015 工具流也非常难用）。Ember 核心团队甚至也考虑过类似的组件整合方式。甚至有人尝试过用 Vue 文件的格式来编译 ng2 组件（虽然坑了）。

（update：现在 Preact 的作者 Jason Miller、webpack 团队成员/微软 Edge 团队成员 Sean Larkin、Ember 作者之一 Tom Dale 和我正在讨论一个跨框架的单文件组件标准）

Vue 通过 Object.defineProperty 改写实现的 POJO 响应式机制，市面上类似的只有 Avalon，这个真的是属于不谋而合，我是在 Vue 发布之后才知道 Avalon 的。React 社区很火的状态管理方案 MobX，其响应式系统原理上跟 Vue 如出一辙。它的 README 里写了：

It is inspired by MVVM frameworks like in MeteorJS tracker, knockout and
Vue.js.

Vue 提出的渐进式框架的理念，也即是『既是框架，又不是框架』，取决于你想怎么用。最近跟 Yehuda Katz 的聊天的时候，他表示 Ember 团队关注 Vue 已经有一阵子，并且觉得在框架/模块化的平衡这一点上 Vue 做到了他们一直想做的。他们也在试图把 Ember 的各个部件做得更解耦更容易被单独使用。

最后，Vue 有一个其他框架真的都没有的理念，同时也是我觉得真正关系到 Vue 的成功的一点，那就是『把高大上的思想变得平易近人』。每个喜欢 Vue 的用户，都会提到容易上手和文档友好。我想说，易用性不是偶然的，做到易用而强大也不是简单的事情，不信你可以试试。对我来说，衡量 Vue 的成功不在于它能让多少人拿来装逼，而是它能让多少人更快更有效率地开发出应用，更早下班回家陪老婆孩子。

至于有人觉得门槛低是 low 的表现，我只能说欢迎你用汇编去写前端，没人拦着你。¯\_(ツ)_/¯