对“渐进式”这三个字的理解：Vue渐进式-先使用Vue的核心库，再根据你的需要的功能再去逐渐增加加相应的插件。
以下理解出处：https://www.zhihu.com/question/51907207
在我看来，渐进式代表的含义是：主张最少。
每个框架都不可避免的会有自己的一些特点，从而会对使用者有一定的要求，这些要求就是主张，主张有强有弱，他的强势程度会影响在业务开发中的使用方式。
比如Angular，他两个版本都是强主张的，如果你用它，必须接受一下东西：
-必须使用它的模块机制
-必须使用他的依赖注入
-必须使用它的特殊形式定义组件（这一点每个视图框架都会，难以避免）
所以Angular是带有比较强的排他性的，如果你的应用不是从头开始，而是要不断考虑是否跟其他东西继承，这些主张会带来一些困扰。
比如React，他也有一定程度的主张，他的主张主要是函数式编程的理念，比如说，你需要知道什么是副作用，什么是纯函数，如何隔离辅作用。他的侵入性看似没有Angular那么强，主要因为它是软性入侵。
你当然可以只用React的视图层，但几乎没人这么用，为什么呢，因为你用了它，就会觉得其他东西很别扭，于是你要引入Flux、Redux、Mobx之中的一个，于是你除了Redux，还要看saga，于是你要纠结业务开发过程中每个东西有没有副作用，甚至你连这个都可能忍不了：
const getData = () => {
// 如果不存在，就在缓存中创建一个并返回
// 如果存在，就从缓存中拿
}
因为你要纠结他有外部依赖，同样是不加参数调用，连续两次的结果是不一样的，于是不纯，
为什么我一直不认同在后台项目中使用React，原因就在这里，我反对的是整个业务应用的函数式倾向，很多人都是看到有很多好用的React组件，就会倾向于把他引入，然后，你知道怎么把自己的业务映射到函数式的那套理念上吗？
函数式编程无副作用，写出来的代码没有bug，这是真理没有错，但是有两个问题需要考虑：
1.JS本身，有太多特征与函数式的主张不适配
2.业务系统里面的实体关系，如何组织业务逻辑，几十年来积累了无数的基于设计模式的场景经验，有太多的东西可以模仿，但是，没有人给你总结那么多如何把你的厚重业务映射到函数式理念的经验，这个地方很考验综合水平的，真的每个人都有能力去做这种映射吗？
函数式编程无bug的根本就在于要把业务逻辑完全都依照这套理念搞好，你看看自己公司做中后台的员工们，他们熟悉的是什么？是基于传统oo设计模式的这套东西，他们认为你拿着你么你给的组件库就知道了一切，但是可能还要被灌输函数式编程的一整套东西，而且没有人来告诉他们在业务场景下，如何规划业务模型、组织代码、还要要求快速开发，怎么能快起来？
所以我心疼这新人，他们呀的只是组件库，却不得不把业务逻辑的撕开方式也作转换，这个事情没有一两年的时间洗脑，根本洗不到开发业务的程度。
没有好组件库的时候，大家痛点在视图层，有了基于React的组件化，把原先没那么痛的业务逻辑部分搞得也痛起来了，原先大家按照设计模式教的东西，照猫画虎还能继续开发了，学了一套新理念之后，都不知道怎么写代码了，怎么写都怀疑自己不对，可怕。
现在我要说说为什么我这么支持Vue了，没什么，可能有些方面是不如React，不如Angular，但它是渐进的，没有强主张，你可以在原有大系统的上面，把一两个组件改用它实现，当jQuery用；也可以整个用它全家桶开发，当Angular用；还可以用它的视图，搭配你自己设计的整个下层用。你可以在底层数据逻辑的地方用OO和设计模式的那套理念，也可以函数式，都可以，它只是个轻量视图而已，只做了自己该做的事，没有做不该做的事，仅此而已。
渐进式的含义，我的理解是：没有多做职责之外的事。