近几年来，前端框架层出不穷，我们不禁感叹，不知道未来两年还会有什么新框架出现。这种无力的感叹，究竟是因为前端的想象力太过丰富，人才太多，各自新式花样的东西会冒出来，还是因为有内在的规律？我相信，作为一个历史学系毕业的学生，万事皆有规律，这种规律支配着下一代编程的可能性。
有些人觉得这是玄学，他认为，之所以有这样的规律，是因为那些东西胜出了，胜者为王，历史都是胜利者书写。然而，如果把逻辑反过来，自问，为什么在众多框架中，vue、react如日中天，为什么typescript越来越被接纳？难道是因为他们本身太过优秀？为什么webpack这么火，打包工具不是没有rollup如此优秀，怎么不是它火爆到如此？为什么seajs挂了？
我认为，更多的原因，是因为他们用最恰当的方式解决了当下开发者的痛点。
抽象化
而痛点是什么？这就是我们今天要讨论的话题。当下这个时代，前端开发的痛点有两个：1.抽象化；2.同构。抽象化是指将某种原本混杂的概念，抽象为某种逻辑清晰的理念，最成功的，当属“Virtual DOM”。同构，是指写一套代码，在不同端使用，PC、手机、服务器……总之，这两点都是当下已经探索出门路的东西，所以，才有那么多东西围绕这两天冒出来。
其实同构这个痛点解决起来轻松很多，大家都有思路，只是方案不同，京东凹凸实验室做了一个项目，叫Taro，用以实现一套代码，构建出在PC、app、微信小程序等多个平台运行的应用。同构大家都有思路，只是方案还没有完善而已。
但是，抽象化，则更像是一个哲学问题，它要研究，要实验，要有理论支撑，要集大成，要有权威人物发言，要有知名厂商站台。因此，在对前端开发规范、标准、模式等各个方面的竞争，就像一场军备竞赛一样，很多人既不甘心，又不得不使用最流行的框架或规范。
也正是因为这样，我们在感觉到这几年前端领域的混乱的同时，似乎也感觉到另外的东西，前端正在范式化，很多问题都在被解决，虽然有些方案看上去还没有变得非常权威，但确实起到了一个探索的过程，这些探索像从四面八方出发，慢慢堆积出前端这座大厦的主体框架，并且已经在添砖了。
举一个例子，前端推行函数式编程。而函数式的特点就是纯函数，纯函数是一个无状态的运行器，无论多少次，只要给的输入相同，输出也一定相同。那么这就会有一个疑问，既然相同输入是一样的输出结果，为何不缓存起来呢？是的，最大的问题是，要以怎样的代码来实现，让开发者可以非常爽的使用这个工具，写最少的代码，以最浅薄的认知，就实现这个效果呢？有一个包，叫reselect，它实现了一套这样的机制。而redux中的reducer也要求是纯函数，因此，把这两者结合起来，就得到了一个答案。
当你读到这里，你可能蒙圈儿了。这篇文章到底要讲什么？下面，我们就将正式的进入我们的话题。
驱动模式
而前端领域抽象化话题下，有个话题不得不单独拿出来讲，那就是程序的驱动模式。
什么是程序的驱动模式？简单的说，就是一套程序里面，它依靠何种模式去运行。一旦在技术选型中确认了驱动模式，这个应用的一生就不得不在这个模式下开发，驱动模式就是它的基因。想要更换驱动模式？不可能的，即便是重构，也不可能，除非你的上级允许你把原有产品当作一个新产品，完完全全重新写过，否则永远无法逃脱这个驱动模式。
举个例子，如果你的应用一开始选择了react作为基本库，那么后面切换到vue或者angular可能吗？不可能。但是，如果你后面切换到taro的体系，可能吗？完全没问题。因为react和taro的驱动模式完全一模一样，因为taro就是按react的模式开发的。同样的道理，使用zetop替代jquery是可以的，使用requirejs替代seajs也是可行的，使用angular2替代angular1比较困难，但大体还是有办法。用rollup替代webpack，用yarn替代npm，用其他什么东西替代babel，只要它们的驱动模式相同，就是可行的，只是需要付出迁移成本。
虽然我的资历尚浅，但是很幸运的是，我接触到了非常多的前端框架（框架级库）。下面我列出：
- jquery
- backbone
- angular
- react
- vue
这里列出来的5个，代表着过去10年来，前端领域最为重要的东西：如何驱动一个应用。
答案很明显，jquery通过简化DOM操作，同时它提供了非常多的辅助方法，让开发者极其迅速的实现应用交互。可以说，jquery就是前端领域的诺基亚，若不是react的出现，它还会过得很舒服。那么问题来了，为什么backbone和angular没有打败jquery？其实说实话，它们根本没有要打架的意思，它们都拥抱jquery。backbone提供的是数据层面的模式，视图操作还是要靠jquery。angular更不用说，干脆直接集成jquery。这究竟是为什么？
实际上，如果你慢慢读我下面的内容，你就会发现，他们是在同一种驱动模式下实现的东西，只是解决了不同的问题而已。其中非常值得一提的是backbone，它是这一时期的最高提炼，甚至有些过了头。backbone的终极，是要建立一套数据驱动视图的机制，但是它只管数据，而不管视图，它差就差了这一步，如果它能够在“驱动视图”这个层面有所突破，比如它在它那个时候想到“数据改动时，找出最小的改动范围，只更新这部分数据对应的视图”这样的方案的话，那么后面可能就没react多少事了。可惜啊可惜，那个时代，思维可能还不能这么超前，所以今天，backbone就像完成了历史使命一样，等待着失去生命那一天。
是的，“数据驱动视图”，是react和vue大获成功的核心所在。react最终找到了突破backbone没有突破的那个点，那就是用virtual DOM来实现数据到视图这个过程。
说了这么多，这5个框架的最本质区别是什么？答案很明显啊：驱动模式。
- jquery、angular、backbone：事件驱动
- vue、react：数据驱动（这里还有更深的讨论）
backbone虽然想要解决“数据驱动视图”这个问题，但是很无奈，它构建了数据响应的一种方式，也就是和jquery、angular一模一样的方式：事件响应。
响应式编程
阅读本文，你需要有一种思维的跳跃过程。终于，你看到了标题中提到的东西。为什么现在才讲到标题上的东西？因为，终于出现了“事件响应”。事件响应，它是响应式编程的一种。
所谓响应式编程，是指不直接进行目标操作，而是用另外一种更为简洁的方式通过代理达到目标操作的目的。举个例子，还是virtual DOM，通过修改数据，实现对DOM的更新。那么问题来了，修改数据到DOM更新这个过程，怎么实现联动呢？再说明白一点，这套代码怎么在我修改了数据之后，去更新DOM呢？如果是react，那就比较好解释，通过setState方法更新状态，并且setState方法内会联动去执行virtual DOM中的diff和patch操作，这样就会更新界面。但是在vue里面就相对复杂一些，vue里面直接修改this上面的一个属性，就可以更新界面了。虽然我们现在都知道，vue是用defineProperty重写了属性的setter，但是这一整套机制实现起来，可不是三两句就说完的。
react之所以好解释，是因为如果单纯讲react本身，它其实在响应式这个问题上和vue有非常大的区别，因为如果单纯看setState，它根本没有响应式，它的响应，是要通过在jsx上绑定事件来实现，因此，单纯看react，它的响应式和angular并无大异，甚至还不如angular。这可能会气坏react的追随者，但事实就是如此。angular的脏检查机制，从体系的层面讲，等同于react里面setState+virtual DOM，而angular里面不需要setState，而是像vue里面一样直接修改数据，编程体验上更舒服的多。那么是什么让react变得不一样？是redux！！！是的，redux及其生态，简直就是这个时代最最最了不起的发明之一，当然，redux是按flux实现的，因此，说Facebook的工程师伟大，也不为过。实体的东西叫了不起，思想的东西才叫伟大。
回到响应式这个话题。
一套代码里面，怎么做到，当一个东西发生了变化，另外一个东西知道它变了，自己也马上作出调整？
我们来看看响应式和非响应式的区别：
// 非响应式
var a = 1
var b = a + 3
var _temp = a
setInterval(() => {
if (_temp !== a) {
b = a + 3
_temp = a
}
}, 16)
上面这段代码超级容易理解。b是依赖于a的，当a发生变化的时候，b也发生变化。那么非响应式是怎么做的？写一个定时器，不断跑，如果在跑的过程中，发现a变了，那么赶紧把变化之后的值运算之后给b，这样b也就跟着变了。
// 响应式
$scope.a = 1
$scope.b = a + 3
$scope.$watch('a', (a) => {
$scope.b = a + 3
})
上面这段代码也比较容易理解。用一个$watch方法去观察a这个属性，如果它变了，马上执行watch的第二个参数函数。“观察”，这个词引出了一个设计模式：观察者模式。被观察的对象，将要观察的部分，以及发生变动后要做什么事情，这两个东西交给观察者，当观察者发现被观察对象的这个部分发生变动的时候，就执行要做的事情。这就是观察者模式的基本思路。这种思路普遍存在于jquery、angular、backbone中，这也是早期框架、库无法逃脱的宿命，它们遵循这一驱动模式。
而响应式编程，就是这一驱动模式下的一种编程方式。开发者写一段代码要实现某个操作时，他并不立即用代码去写这个操作，而是使用了一个代理（这个代理一般由框架或库实现），这个代理的作用是，当用户进行了某个操作时，触发了某个变动（事件或数据变动），而这个变动触发了代理中的某些特定项，而这些特定项被触发时，和它们绑定的目标操作就会自动执行。虽然这个过程比直接用代码写操作过程本身复杂，但是对于开发者而言不是，开发者只写用户进行操作时会触发哪个变动，这样代码量就极速下降，甚至只需要一行代码。
这就是响应式编程的优势，它利用代理（一般是经过高级封装的一套逻辑）阻断了变动和操作的直接关系，而是将变动和操作分离，但通过代理，又可以准确的执行变动带来的操作。
响应式的分流
当知道什么是响应式编程之后，我们就该讨论vue和react+redux的不同了。不过我可不是直接的人，在没有理清楚逻辑的时候，直接告诉你答案显得轻浮。
我们接下来要讨论的是，世界上都有哪些已有的响应式编程。原来，响应式编程还要分流派。没错！
事件响应
这是我们最早知道的一种响应式编程方式。时间倒退10年，我们会在网页中，利用DOM节点的事件钩子来做一些事情，例如当用户输入关键字的时候，利用xhr搜索，让用户可以看到一个推荐列表。现在听起来这个功能好土啊，但是回到10年前，真的不得了，我记得百度是2010年才有这个功能的吧。
但现在是2018年了，事件响应简直简单的要死，连HTML5都规定了addEventListener这样的api，简直抢了jquery的饭碗。但是，我还是要提backbone，虽然这件事是jquery先做的，什么事？那就是抽象出事件响应的书写方式，也就是提供on/off/trigger这三个主要方法，实现一整套事件的绑定、解除、触发逻辑。之所以觉得backbone更高级，是因为backbone试图完全脱离view层面，jquery的这些方法，大部分还是向DOM节点绑定事件，但backbone完全是自定义事件，脱离了DOM事件体系，触发事件是为了修改数据。
angular里面对事件响应做了更高级对封装，它把对DOM节点绑定的事件和对数据操作绑定的事件这两件事抹平，成为一件事，它把点击抽象为ng-click，ng-click实际要做两件事，一件是绑定事件到DOM节点上，另一件是当DOM事件被触发时同时触发绑定的数据操作。因此，当ng-click传入的函数被执行时，会同时执行所有$watch的函数，实现脏检查。angular本身实现的是backbone那一套事件响应，但同时，它也借助了DOM事件响应的原生特性。这使得angular成为早起最不得了的框架。
数据响应
借鉴于angular，但和angular不同，vue走了另外一条路。vue要做的，是解决backbone没有解决的问题。它不去寻求中间的那一层代理，而是直接实现数据变动的联动效果。在前面举例一个数据变了另外一个数据跟着变的代码的时候，有一种更快速的实现方式：
var a = 1
var b = a + 3
function setA(value) {
a = value
b = a + 3
}
在每次想要修改a的时候，调用setA，而非直接a = 0，这样可以做到a变的时候，b也跟着变。这叫响应式？如果非得说概念的话，这还真是，只是代码看上去不那么优雅吧。
不知道你有没有用过chai.js，里面有一种should方式。这种方式修改了整个作用域，使得要测的变量拥有了should属性，非常了不起。为什么要讲这个？因为我们也可以用一种方式，不要用setA这么俗的方式修改a，因为太不直观了，我就想要a = 0。
vue就是干了这么一件事，它抹掉了setA这个操作，使得直接修改this上的某个属性时，就可以触发目标操作（更新界面）。这种将其他操作抽象到数据操作上的响应模式，就叫“数据响应”。它把对界面操作的目标，抽象为对数据操作，也就是抹平了angular里面的$watch，抹平了backbone里面的on/trigger，其实也就是抹平了事件响应里面的“观察者”这个环节，也就是不需要观察者，因为它不依赖于事件。
基于数据响应，其实可以做非常多的事。在vue里面，数据响应的下一步是通过virtual DOM实现界面的更新。而如果将这个模式运用到服务端开发，也是可以的。我之前发布了自己写的最新的包objext，它就是将数据响应抽象化，使得数据响应脱离vue这种要操作界面的具体场景，数据响应，应该可以运用于任何场景。当然，objext只是一个非常小的东西，如果想要更加高级功能的，可以了解下mobx。
事件流响应
2018年真是多事之秋，原本以为数据响应，已经是最了不起的模式了，然而，RxJS的突然爆热，让响应式编程出现了新的视野，原来以为只有事件响应和数据响应，没想到响应式里面还有新的风骚操作。
RxJS并非完全首创，实际上HTML5已经有类似的东西出来了，那就是MutationObserver，这个看上去很容易让人忽略的接口，却对于一不小心看到的开发者来说，简直就像捡到一块宝。MutationObserver将DOM的操作变为可观察的，在这之前，我们操作DOM，没有一个事件可以知道，一个DOM节点是不是被删掉了，是不是被修改了，而有了MutationObserver之后，就可以做到了。既然DOM是一个对象，那么基于同样的逻辑，能否实现一个东西，可以让一个普通的js对象也可以转变为可观察的呢？RxJS孕育而生。了解RxJS的同时，需要了解ReactiveX，也就是说，这是一种编程方式，它在不同的语言中被实践，不单单包括js。
那么到底什么是ReactiveX呢？官方的定义是：
ReactiveX is a combination of the best ideas from
the Observer pattern, the Iterator pattern, and functional programming。
它将事件再度抽象，因为一个应用中，事件往往不是单独存在的，而是一系列事件相继被触发，因此，它提出了streams的概念，也就是“流”，事件流，总结起来，它就是基于“可观察的事件流”的编程方式。当然，它提到了自己是函数式的编程，这可能是为了蹭热度，强制要让开发者体验最新潮的开发方式，但函数式并非它的最终极目标，没有函数式，它照样让开发者体验极致开发，有了函数式，使得它熠熠生辉。
那么，RxJS到底优秀在什么地方呢？RxJS的本质和事件响应一样，是观察者模式的一种实践，通过内部机制，实现观察者，同时开发者可以通过subscribe方法进行订阅，从而在特定的事件中，达到自己的目的。但是，单有观察者模式的实践不足以使它优秀，构建“流”才是它的杀手锏。RxJS是怎么实现“流”的，那就是它结合了迭代器模式。
什么是迭代器模式？就是开发者可以自己创建一个迭代器，在遍历过程中，开发者创建的这个迭代器规定了遍历的内在逻辑。在RxJS开发时，开发者可以自己规定迭代器，把迭代器作为被观察对象，这样，在运行过程中，事件流（本质上是一个事件订阅序列）就会安装迭代器内的逻辑进行流动。
除此之外，RxJS更是抽象出事件与数据之间的映射关系。我们都知道，virtual DOM抽象出了数据和真实DOM的映射关系，数据改变，DOM改变。RxJS则是抽象出事件与数据之间的映射关系，事件发生，数据按照规定发生变化。RxJS通过各种map方法，抹平了事件和数据、事件和事件的分离状态，使得事件在RxJS的体系里面，是有序的，可映射为数据变化的东西。因此，RxJS里面的响应方式是：你不需要关心事件本身，而只需要关心事件所映射的数据变化。
虽然RxJS的编程体验非常好，但是有一个问题在于，它是完全新的驱动模式。它不仅改变了开发者的开发习惯，更重要的是，它对项目具有侵入性。我已经说过，要使得一个已有的项目改变驱动模式，是不可能的，如果要在一个原有项目中重新使用RxJS，几乎不可能。而且它的api超级多，使得新晋的开发者可能望而却步。但现在已经是2018年了，什么样的复杂模式不应该了解一下呢？
数据流响应
很明显，有“流”的概念之后，“数据流”的概念也呼之欲出。数据响应和事件响应的区别是，不需要“观察者”，对数据的操作更加直接。但是有一个问题是，当一套复杂的数据响应被应用于一套复杂的应用中时，开发者往往在响应来响应去的连环嵌套响应中被搞昏头，因为数据的响应而牵一发动全身，导致整个响应很难控制，这是数据响应必须解决的问题。
为了解决这个问题，vue推出了vuex。react本身就没有响应，数据是单向流的，不存在这个问题，但是也正因为react没有响应，所以开发体验极差，因此，有了redux和react-redux。
数据流响应的本质，是一个状态机。它确定了数据在某一时刻的特定状态，数据的不断变化是可以被监控的，上一个状态是什么，变化后现在的状态又是什么，都可以被开发者知道。靠什么来维持这种数据流呢？redux发明了reducer机制，通过纯函数式的状态更改器，来保证每一个状态都是独特的不被污染的。
但是，实际上，redux在“响应”上做的并不完美。react-redux顶多做到了“状态的改动自动映射到界面的改动”，但是它没有解决的是，在数据和状态之间做好映射。现在的redux，你需要创建action和触发dispatch，有没有一种方式，可以不需要手动去触发dispatch，数据的响应是事先安排好的，当数据发生变化时，自动dispatch？这样可以更完美的提升开发体验。虽然mobx是这样的，但是它忘记抽象出数据流，用mobx管理数据，更多的是看中它的响应，但你不能保证对整个应用的状态的准确把握。
由此，在“数据流响应”这个点上，实际上，还没有一套完美的解决方案。另外，有人将RxJS和redux结合起来，既发挥了RxJS在事件管理上的优雅，又保证了数据流的准确，但这一结合也仅仅主要是为了解决redux在异步数据数据处理中的问题，没有真正抽象出数据流动本身的管理。或许，接下来的一两年，冒出来的新东西，就是在解决这个痛点也说不定。
小结
本文从前端的开发体验入手，阐述了“抽象化”“驱动模式”“响应式编程”等问题。前端编程是面向用户体验的编程，它不仅要考虑界面呈现的友好、业务逻辑的准确，还要考虑在编程中如何精准、快速地响应用户操作。响应式编程，是未来的一个趋势，但响应式编程不只有ReactiveX，不应该一提到响应式编程，就限定于ReactiveX。它是一整套抽象逻辑，除了本文提到的四种响应式之外，说不定再两年，又有新的响应式也不定。
