Angular是最早且最完善的前端工程框架，虽然已经有很长的历史，但是它所蕴含的一些思想，值得我们借鉴。而react和vue是同时代的产物，两者之间没有必然的联系，但是不可否认的是vue吸收借鉴了来自react和angular的优点，我不能说它是用以开发最舒服的框架，但是从它完善而友好的文档而言，真的对开发者是一种非常友善的表示。但抛开框架本身的热度，我们怎么从技术本身，从我们作为程序员的编程体验来分析和对比三大框架呢？

编程范式

编程范式简单理解就是编程的风格，开发者如何去思考一个逻辑在这个框架下应该如何实现。如果你现在还不能理解这一点，读完本节你应该有所感悟。

三大框架的编程范式完全不同。

Angular首先有一个作用域的概念，启动一个应用通过html属性或者代码指定来启动。有点像express创建一个app一样。你可以对这个app注入很多依赖，挂载指令，通过创建controller来隔离出新的作用域，父作用域和子作用域可以原型继承，当然也可以完全孤立。你还可以注入服务，以及其他。大部分项目会注入ui-router到config中实现路由。处理好应用的整体代码结构之后，就是无止尽的模板和controller代码撰写了。当然，为了提供功能，撰写服务注入也很常见。另外就是要自己写directive。angular编程大体就是这样。但是在实际上，你会踩到很多坑。例如路由，例如作用域继承与隔离，这些都要在开发中慢慢去解决。

React的开发则简单的多。因为单纯写react组件，你只需要写一个继承于React.Component的class，然后在它的render方法里返回jsx即可。一个组件写完了。为了让界面响应数据变化，你要学习virtual dom的机制，然后用setState修改state信息，并在jsx中使用这些state。但是要完成交互，所以你要学习react的事件系统，然后做类似angular一样的事件绑定。然而，react的数据流是单向的，如果在子组件直接修改props，不仅不能重新渲染界面，而且还会产生副作用。所以，你不得不在props上传入一个函数，作为桥梁，实现内外组件交互。一旦组件多了，这种交互极其麻烦，于是你需要考虑引入状态管理器了，redux出现在你的视野。要让一个组件在页面中运行，你需要使用react-dom，为了满足更方便的界面切换，你又得考虑一个配合react的路由组件。之后你还会遇到生命周期，异步等等问题。哦，对了，你还得会用babel之类的工具。

Vue编程直接模拟了程序员对一个东西的直接思维。它创造性的发明了.vue文件，你可以把一个组件的模板，js代码，样式代码写在这个.vue文件里，借助webpack的loader完成对组件的编译。写vue组件思维之所以简单，是你会觉得自己在写配置：配置模板，配置样式，用js来配置组件要用到的数据，以及组件生命周期、事件响应和抛出、必要的函数，等等。和react一样，你也需要通过Vue内置的方法来启动一些组件，并且会遇到一模一样的路由、状态、异步等等问题，而这些你都需要使用对应的包或某种规则去解决。

Angular1.x vs. Vue3.0- vs. React16.0-

我们在讨论这三个框架的时候，无法绕过它们最原始的版本，因为三个框架的原始思想来源于初创者在设计之初，就遵照了一定的思想去实现各个部分，因此，在这种设计之下，它们在写代码的时候，所采取的逻辑思路是不一样的，这就是它们在编程范式上的不同。angular1.x版本，vue3.0之前的版本，react16.0之间的版本，都是这三个框架的经典版本，而对这三个经典版本进行对比，能够更好的理解它们作为框架的本源（虽然很多人强调react并非框架）。

AngularJS vs. Angular

在angular发布2.0之后，angular1.x版本被称为AngularJS，而angular2.0以后就叫Angular。去掉JS是因为angular采用了typescript作为编程语言。从本质上讲，js和typescript是两个不同的编程语言，而联系在于，typescript现阶段必须编译为js来运行，而未来，将会有解析器直接运行typescript代码。Angular除了在编程语言上去掉js标记，另一个重要的点在于，它修改了自己最原始的编程范式，并且希望更多的于时代贴近，试图在多端开发中占据一席之地。

React16.0- vs. React16.x

React16.0重写了React，引入了Fiber的概念，这对于开发者而言几乎无感，但是Fiber相当于在渲染机制上重新改写了React，反过来说，它虽然可能带来更顺滑的渲染，但是也会给开发者挖一些坑。但是无论如何，React16都是一个特殊的版本，后续加入的context api和hooks，特别是hooks，将会改变原始的react编程习惯。

Vue3.0- vs. Vue3.0

vue不久前证实了vue3.0版本，并且已经发布，这让很多开发者发出“学不动”的感叹。但是不可否认的是，vue3.0使得vue在编程习惯上来了一个天翻地覆的变化，当react开始通过hooks来削弱对class的开发依赖时，vue3.0却完全支持react16.0-类似的class写法。从某种意义上讲，vue不大可能超越react，但这种版本的变化让我们也有了更多的选择。

模板 vs. JSX

下面开始，我们来讨论经典的三个版本。

angular和vue都是基于模板的（vue也支持jsx），react诞生时就是基于jsx。jsx看上去像是模板，但是实际上它并非模板，而是创建UI视图的函数集的语法糖，当jsx被编译为js之后，是一大堆函数调用的集合，因此，不存在模板。一旦存在模板，那么在js的运行时，就需要对模板进行解析，并且同时执行创建UI的过程，效率上是打折扣的，而jsx相当于直接创建UI，没有解析模板过程，对于相同结构而言，自然要更胜一筹。

脏检查 vs. Virtual DOM

从本质上讲，脏检查和virtual dom没有可比性。但是，这两个词代表了angular和vue、react在更新视图机制上的典型词汇，因此，实际上，我们要讨论的是，三大框架，在数据（model）发生变化时视图（view）如何对数据进行响应并做出对应的变化，这样的一个问题。

几乎所有的人都知道angular赖以成名的脏检查机制，但是它的究竟是怎样的运作机制？我在以前的博客中专门有一篇文章详细讲解了angular脏检查机制，如果有兴趣可以提前阅读。但实际上，脏检查机制仅是在数据变化中，确保angular已经收集到所有的数据变化，真正要进行界面的更新，仍然需要angular内置的视图渲染和更新渲染的相关机制。

同样的道理，在vue和react中，也有一套系统，在数据变化时确保收集到数据的变化，vue是内置的数据代理，让我们可以直接修改数据对象属性来触发数据变化通知，而react里面则是依赖props和state，以及内置提供的一些方法。在渲染和更新界面时，才用到了virtual dom的机制。

虽然脏检查和virtual dom是在不同阶段的不同概念，但是数据变化和对数据变化做出界面响应，这两个阶段是构成三大框架内在最本质的特性，因此，这两个阶段是不可分离的，把这两个概念放在一起也可以笼统总结出三大框架的界面响应机制的区别。

指令 vs. 组件

angular发明之时，前端组件的概念还没有火起来，angular发明了directive（指令）用以在模板中自定义一些新的html属性，拥有这些属性的html标签将拥有新的功能，而这些功能的实现，靠angular directive的js代码实现。在后来，angular也有组件的概念，但是也仅仅是对directive的特殊化，并非我们现在讲的真正意义上的编程化组件，所以，当你打算对一个已有的“组件”进行功能增强时，你会非常烦恼。

而react和vue诞生之初就是基于组件的概念，可以说，我们在用react和vue开发时，大部分时间是在写好一个组件。基于怎样的风格写好组件并不简单，在经典的vue中，写一个组件更像在写一个配置，通过配置对象的不同属性来规定组件的动作和效果，而react基于class的写法，让组件编程更像是原生编程。

无论是哪一个框架，在组件概念下的代码单元，在运行时都有“生命周期”的概念。

全家桶 vs. 散装

大家常说的一句话是，“react全家桶来一套”，然而实际上，angular是全家桶，react是散装，vue是半桶水。angular开箱即用，自带了$http（为了解决异步场景下的脏检查，$timeout是同样的目的），通过依赖注入的方式提供需要的功能。但react要真正用起来非常麻烦，你起码需要react和react-dom这两个包，否则根本跑不起来。

但是，从现代编程的角度讲，显然react的这种散装模式更符合编程的内在需要，它内在解耦了不同目标的功能，react负责将界面抽象为代码，不要考虑运行的环境，一旦这种抽象思维被发现，那么我们可以想象的空间非常大，同样的一套代码，都是界面的抽象描述，那么是不是用不同的解析器去解释它，就可以适配不同的客户端呢？比如在手机上生成基于特殊技术的原生app等等。

除了提升想象空间外，散装模式，还可以降低学习成本，开发者不需要某些功能，则不用去学习对应的套件。同时，也可以降低整个应用打包后的尺寸。

MVVM vs. MV

Angular是典型的经典MVVM框架，作为开发者，你需要自己撰写视图、控制器，控制器中用$scope管理数据，通过更改$scope上的数据，和angular内置的事件系统，解决复杂的交互逻辑。虽然从理论上这样的编码逻辑没有任何问题，但是因为要把所有的js业务代码都写在一个函数内，通过$scope导出，并且在函数内实现各种复杂逻辑。另外，angular的依赖注入要求你把注入的服务作为该函数的参数导入，这些在现在看来（ES6之后），实在是太憋足了。angular虽然解决了很多问题，但是仍然留下了很多坑给开发者。它像一个大而全，但不灵活的框架，使得很多逻辑要写重复的代码去实现。

而React所提倡的组件方式，则使得编程更加清晰。你需要定义的是，视图，视图用到了那些数据，这些数据如何变动。虽然听上去也差不多，但是整个编程体验是非常舒服的。你不需要考虑依赖注入，也不用在模板和控制器代码之间来回切换。组件代码复用性强，且易于扩展。比较麻烦的是，react没有angular的双向绑定，内部的变动不能反馈给外部，这又给react在编程上带来了特别复杂的体验，你需要反复在组件中通过props来传递内外数据交互，而且传递过程并不直观，你需要在props上放一个函数，在内部适当的时候调用这个函数，并把内部的数据作为参数传给这个函数，而该函数又是外部定义的，当它被执行时，相当于又可以去执行外部的一些逻辑。为了给这种不方便一个好的解释，Facebook的团队称这是因为react采用了单项数据流来控制数据，单项数据流使数据变动更清晰容易理解，出bug的几率会降低。但是事实证明，bug从来不会减少。虽然redux利用这种单项数据流可以做非常棒的功能，例如数据快照（用以还原用户操作）等，但是这并不表示react在这一点上是成功的。

vue竟然在这一点上站在了react一边，这让它显得非常没意思，不断的复制react。vue有一个v-model指令，非常好的继承了angular的思想，但是，双向绑定也仅仅限于v-model而已，在内外组件之间，它和react没有区别，而且，更无聊的是，你需要在子组件中显示的声明外部传入哪些props是被接受的。从这一点上，就让vue大显失色。从某种角度讲，vue是一个试验性的框架，借一点angular，借一点react，听说typescript不错，也上typescript，没有特别的灵魂。而且从开发体验上讲，vue也并不特别令开发者舒服，你需要显示的声明要用到的组件、props，在没有context的前提下，你可以在属性中使用this，而这个this到底指向谁，在编程的时候你完全是错误的，因为当一个属性函数中定义了this，从js本身的默认行为上，this应该指向该对象，虽然我们知道，在vue内部，会将this指向自己的实例，但这就违背了js编程的内在意义，使得代码让人捉摸不透。

总结起来，三大框架的经典版本，在编程体验上都不如人意，总觉得有点不足之处。

趋于一致

随着新版本vue的发布，三大框架开始趋于一致，有一篇文章提到

Follow 标准是趋势，如果能够引领标准，那将是框架的无上荣耀

虽然这样说并不一定正确，毕竟技术需要多元化，标准之外也有珍宝，但是从目前的现状而言，也正是这个道理，向web components标准看齐已经是多数框架的基本原则，来自腾讯的OMI框架则更是在这一点上贯彻至极。一旦在编程体验上和web标准一致，那么我们可能会产生这样的疑问：选某个框架去写还有什么意义？反正写出来的代码都差不多。话虽如此，但我们可以这样看待，我们并非选择某个框架去写代码，而是我们写了标准模式的代码，现在是选择用什么框架去运行。

在这一点上，react再次走到了前面。react官方在博客中再次强调，他们不会移除class这种编程方式，但是他们更提倡开发者采用function的编程方式。

2019-03-22 9738