框架架构
常见的架构为三种，MVC,MVP,MVVM。后两者是 MVC 的变种。
MVC 与 MVP
具体介绍参考：
在 MVP 中，模式将 Controller 改名为 Presenter，三层之间的通信，变为都是双向的。
具体来说，之前的 MVC 内部数据流是一个环，并且数据流动是随机的，随业务逻辑而变。MVP 变成了一个垂直的管道，数据流动为垂直双向，变得扁平化：model 和 view 无法直接互操作了，必须通过中间的 presenter 来连接。
MMVM
在 MVP 中，view 变化会影响 Presenter，而 Presenter 又会由于 Model 数据的更新，去改变 view。这个特点，是每一个基于 MVP 架构的项目都会有的，必须实现的一个逻辑。为什么不把它作为一个库单独实现出来，别人只要用提供的 API 就可以了呢？
在 MVP 的基础上，为视图层和 Presenter 提供了数据双向绑定的服务。这就是 MVVM 了。在 MVVM 中，当中间的控制层（叫法从 Presenter 变为 ViewModel）的相关变量变化的时候，MMVM 项目的默认内置库（比如 vue 框架）就会检测到该变量将会导致视图更新，就自动去更新；当视图 DOM 变化的时候，vue 捕获到它将影响 ViewModel，也就是我们在项目中声明的变量的值，就去更新。
MVVM：优势与缺陷
为什么要用它
我们知道，数据双向绑定不需要自己去实现。相对于之前需要自己去手动实现，然后在开发的过程中不断 debug、在 HTML DOM 代码和 js 逻辑上面反复横跳，MVVM 在 代码开发速度 和 可维护性 上都有质的飞跃。虽然现在仍然需要在 DOM 和 JS 之间跳，但更简单了，因为不需要调试 DOM 的响应式属性。这是 MVVM 的主要优势。
它会带来什么问题
内存
但是，对于使用第三方库实现数据双向绑定，不可避免的会产生临时数据 book-keeping data。也就是临时数据。
对于一个通用性和健壮性非常强的数据绑定库，其代价往往是需要占用更加多的内存，用于存放临时数据。尤其对于大型项目而言，在数据绑定收集依赖的过程中，我们不得不为每个对象产生几个、甚至几十个的临时变量和设置缓存，这会造成内存膨胀。
性能
对于简单的小项目，手动的实现响应式，和用第三方库实现响应式，显然后者的性能是绝对无法优于前者的，除非你 coding 能力实在太菜。因为后者需要考虑的东西太多了，而如果手动实现的话，就可以直接去针对元素进行操作，不仅更加定制化，而且更快，什么外部影响都不需要考虑。
这也构成了 vue3 把响应式从默认全部是响应式数据，变为可选 ref 声明的理由。并不是每一个数据都必须是响应式的，数据绑定操作是可选的，如果你想的话，可以自己手动实现自己的数据绑定（当然，我觉得很少有人为了追求那么点性能而这么做...vue 的响应式已经被证实可以用于大型项目，比如 某bili。）
Vue.js的目标是通过尽可能简单的 API 实现响应的数据绑定（MVVM）和可组合的视图组件（SFC）。