渐进式代表的含义是：主张最少。

每个框架都不可避免会有自己的一些特点，从而会对使用者有一定的要求，这些要求就是主张，主张有强有弱，它的强势程度会影响在业务开发中的使用方式。

比如说，Angular，它两个版本都是强主张的，如果你用它，必须接受以下东西：

- 必须使用它的模块机制
- 必须使用它的依赖注入
- 必须使用它的特殊形式定义组件（这一点每个视图框架都有，难以避免）

所以Angular是带有比较强的排它性的，如果你的应用不是从头开始，而是要不断考虑是否跟其他东西集成，这些主张会带来一些困扰。

比如React，它也有一定程度的主张，它的主张主要是函数式编程的理念，比如说，你需要知道什么是副作用，什么是纯函数，如何隔离副作用。它的侵入性看似没有Angular那么强，主要因为它是软性侵入。

你当然可以只用React的视图层，但几乎没有人这么用，为什么呢，因为你用了它，就会觉得其他东西都很别扭，于是你要引入Flux，Redux，Mobx之中的一个，于是你除了Redux，还要看saga，于是你要纠结业务开发过程中每个东西有没有副作用，纯不纯，甚至你连这个都可能不能忍：

const getData = () => {
// 如果不存在，就在缓存中创建一个并返回
// 如果存在，就从缓存中拿
}

因为你要纠结它有外部依赖，同样是不加参数调用，连续两次的结果是不一样的，于是不纯。

为什么我一直不认同在中后台项目中使用React，原因就在这里，我反对的是整个业务应用的函数式倾向，很多人都是看到有很多好用的React组件，就会倾向于把它引入，然后，你知道怎么把自己的业务映射到函数式的那套理念上吗？

函数式编程，无副作用，写出来的代码没有bug，这是真理没错，但是有两个问题需要考虑：

1. JS本身，有太多特性与纯函数式的主张不适配，这一点，题叶能说得更多
2. 业务系统里面的实体关系，如何组织业务逻辑，几十年来积累了无数的基于设计模式的场景经验，有太多的东西可以模仿，但是，没有人给你总结那么多如何把你的厚重业务映射到函数式理念的经验，这个地方很考验综合水平的，真的每个人都有能力去做这种映射吗？

函数式编程无bug的根本就在于要把业务逻辑完全都依照这套理念搞好，你看看自己公司做中后台的员工，他们熟悉的是什么？是基于传统OO设计模式的这套东西，他们以为拿着你们给的组件库就得到了一切，但是可能还要被灌输函数式编程的一整套东西，而且又没人告诉他们在业务场景下，如何规划业务模型、组织代码，还要求快速开发，怎么能快起来？

所以我真是心疼这些人，他们要的只是组件库，却不得不把业务逻辑的思考方式也作转换，这个事情没有一两年时间*，根本洗不到能开发业务的程度。

没有好组件库的时候，大家痛点在视图层，有了基于React的组件化，把原先没那么痛的业务逻辑部分搞得也痛起来了，原先大家按照设计模式教的东西，照猫画虎还能继续开发了，学了一套新理念之后，都不知道怎么写代码了，怎么写都怀疑自己不对，可怕。

我宁可支持Angular也不支持React的原因也就在此，Angular至少在业务逻辑这块没有软主张，能够跟OO设计模式那套东西配合得很好。我面对过很多商务场景，都是前端很厚重的东西，不仅仅是管理控制台这种，这类东西里面，业务逻辑的占比要比视图大挺多的，如何组织这些东西，目前几个主流技术栈都没有解决方案，要靠业务架构师去摆平。

如果你的场景不是这么厚重的，只是简单管理控制台，那当我没说好了。

框架是不能解决业务问题的，只能作为工具，放在合适的人手里，合适的场景下。

支持Vue可能有些方面是不如React，不如Angular，但它是渐进的，没有强主张，你可以在原有大系统的上面，把一两个组件改用它实现，当jQuery用；也可以整个用它全家桶开发，当Angular用；还可以用它的视图，搭配你自己设计的整个下层用。你可以在底层数据逻辑的地方用OO和设计模式的那套理念，也可以函数式，都可以，它只是个轻量视图而已，只做了自己该做的事，没有做不该做的事，仅此而已。