Vue2.0 中,“渐进式框架”和“自底向上增量开发的设计”这两个概念是什么?

在读 Vue2.0 文档的时候,介绍“Vue.js(读音 /vjuː/, 类似于 view) 是一套构建用户界面的 渐进式框架。与其他重量级不同的是,Vue 采用自底向上增量开发的设计。” 那么问题来了,什么是“渐进式框架”?什么是“自底向上增量开发”? 可否结合 Vue 具体的谈一谈,谢谢!
关注者
445
被浏览
30813

11 个回答

在我看来,渐进式代表的含义是:主张最少。

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

比如说,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和设计模式的那套理念,也可以函数式,都可以,它只是个轻量视图而已,只做了自己该做的事,没有做不该做的事,仅此而已。

渐进式的含义,我的理解是:没有多做职责之外的事。
我的观点和叔叔 @徐飞比较像,我简化的说一下,如果徐叔觉得不是一个意思那我就删了前面那句话。

总的来说,它给你提供足够的optional,但并不主张很多required。

我们常说:做减法比做加法难。
我觉得一个框架如果是“渐进式”的,就意味着,它本身承担了较难的做减法的部分,而留给它的使用者较简单的做加法的部分。

就是说,在我们用一个工具的时候,并不是为了用其中的某一个部分,而想办法无视或者裁剪掉其他部分(做减法),而是上手就可以用上它的大多数功能,再在需要的时候引入它的官方或第三方插件(做加法)。
这样站在使用者的视角就会更省心了,就好比给你一个空屋,通了煤水电网,有床够睡,需要什么自己添;亦或给你拎包入住,但住了一阵子这不满意那不满意。

比方说,jQuery的核心对于大多数使用者都是有用的,包括selector、事件、dom操作、class操作……因此我们不太会从一引入就开始想着要裁剪它——当然从今天的眼光看来的话也许是越来越想了2333。
为什么?