Vue.js
vue对比其他
一套用于构建用于界面的渐进式js框架。
构建用户界面：将拿到的数据通过某种办法变成用户可以看见的界面。
至于怎么拿到的data，至于是发送请求、还是固定不变，vue不关心。
原生js是手动挡；jquery是自动挡但是转弯、油门还是需要你动手，jqueyr是类库而非框架；vue是无人驾驶，功能完善大而全说明目的地即可。
vue特点
组件化开发,提高代码复用率，且更易维护。
一个.vue文件就是一个组件，包括html骨架，css样式，js交互，一旦新项目或者别人想用，直接拿过去.vue文件，修改一下内容以及请求地址，数据渲染逻辑就可以复用了。
最大的好处就是更好维护，假如一个页面多个组件，当你修改一个组件里面的css样式，绝对不会影响其他组件的css，即便是重名了。
声明式编码提高开发效率。
虚拟dom+diff算法，尽量复用dom节点：
当数据变化了，可能只是多了一条数据，前面你还有三条和之前一样，原生js是将重复的数据也删除，重新将数据进行渲染。
而vue在数据与dom之间，创建了虚拟dom，会先将数据变为虚拟dom，然后将虚拟dom渲染到页面真实dom上，虚拟dom就是内存里面的数据
当有新的数据时，新的虚拟dom会与旧的虚拟dom进行比较，当发现标签、属性等都一样的时候，会直接复用。
类库与框架的区别：
类库对项目的侵入性小，性能或其他有新的改变，更换一种实现即可。
框架对项目侵入性大，更换版本还好说一点，如果更换框架要重新架构项目，但框架提供完善的解决方案。
早期的前端就是html和css，根本没有js，就和pdf文件没有区别，随便刷新。
但应用越来越五花八门，更像app的感觉，刷新会导致用户体验不好，刷新的本质是摧毁dom，然后重建dom。
谷歌提出SPA的改变，单页面应用，全程无刷新，全程就一个dom不摧毁，在一个dom里面来回切，即MV*模型，而vue属于其中的MVVM。
MV*看待问题的世界观变了，从早期的前端校本化向前端工程化迈进。
背景：
1：js框架，尽管已经有了jQuery，但是jquery还是需要你动手去操作dom。jQuery是命令式，vue是声明式，jQuery渐渐退出历史舞台。
2：ES6之前js没有OOP，尽管可以做成闭包，但是很丑陋，可读性弱。
3：原来的网页和静态页面几乎无异， ajax还好一点，比较平滑，就像图片一样频繁刷新无所谓，但是越发展越无法容忍，因为需求越来越像app。
4：es6之前，js代码很烂，bug很多。
刷新的本质是摧毁原来的dom，进行重新渲染，关键恶心的是原来页面里面的数据没有了，上一个页面的变量不能直接携带到下一个页面。
举个不会这么做，但是道理一样的例子，第一页写username，第二页写密码，写完第一页到了第二页，username不想用了，要退回去，退回去不希望username是空的吧？
此时你就不得不做恶心的事，要么把上一个页面的数据寄存到一个地方，到了下一个页面再把数据取出来放到新的页面里面，这是最恶心的。
尽管你可以放到session中暂存，或者放redis中，要么就放数据库里面，放到远端，传回来又要时间，访问量高了服务器压力立马上来了。
4：因此出现了SPA：single page application概念，单页面应用，页面全程无刷新，在一个dom里面来回切。
概念梳理
js框架发展史
第一代：jquery操作dom，尽管比原生js好的多，代码量少了，但是程序员还是需要调用api去操作dom，最恶心的是js代码里面充斥着填充html的代码，二者耦合在一起。
第二代：MVC，代表就是react，尽管这是前端的模型，
实例：现在有个项目，分别是PC端、手机端、ipad端
这里有两个MVC，一个是后端的MVC、一个是前端的MVC
后端：M：指数据库
C：指接口，例如Django里面的视图函数
V：指的是整个前端。
前端工程化后也分MVC：
M：后端传来的json数据
V：指的是dom，你可以看到的页面。
C：指的是你用js代码或jquery写的，抓取dom树，提取json数据，塞到dom树的逻辑代码，可以视为一些函数。
第一个周：项目经理让开发一个PC端页面
PC端显示LOL玩家的对局场数，KDA，段位，等级，日期，假设这些数据就在一张表内。
此时后端开一个接口，从数据库拉出数据，打成json回应前端。
前端拿到数据作为M，然后用js写Controller，将json数据处理，爬取dom树，将数据塞进去，
然后view显示数据。
第二个周：项目经理让开发手机端
手机端显示玩家的KDA、段位、等级即可
此时后端又开一个接口，同样从相同的表中拉取数据，打成json回应前端。
前端拿到数据后，写新的Controller，因为数据变了，页面也变了，重新抓取dom树，将json中的数据塞进去。
view显示数据
第三周：项目经理又来了，让你开发ipad端
ipad端让你显示玩家的KDA和段位，此时需要将数据处理用柱状图显示kda
后端又开一个接口，还是那张表拉数据，打成json回应前端
前端拿到数据后，写心得Controller，然后同上。
这三个小项目，后端开了三个接口，却都是对同一张表中的数据进行了自以为的，按需求的数据截取处理。
为什么不能一次性将所有数据都传过去呢？为了降低IO？为了优化？
最后是，DB不变，写了三个后端接口，传给前端三份不同的数据，前端写了三个controller处理json和dom，渲染了三个不同的view。
|<------------------------------------------------------------------------------------>| |<---------------------------------------------------------------------------------------------------------->|
但实际上， 完全可以共用一个后端接口，三个view公用一个data 前端的controller逻辑完全相同只是处理的数据不同而已，完全可以复用，经过配置达到高级复用，即框架
忽略后端看前端。
此时前端共用后端一个接口传来相同的M，View是不同的，C同样不同。M得到复用。
新项目，页面和刚才的项目完全相同，只是底层的data不同，如何开发？
拷贝过来改改后端的sql接口逻辑，假如v完全相同，此时的c你不能复用，因为c与data相关，新项目传来的data与原来不同，只能将controller拷贝后进行修改
一个单独M+一个单独V，决定一个单独的C
此时发现第一个项目的data可以复用，第二个项目的v可以复用，而c始终无法复用，你成了C，总是站在需求的角度上不停的改动，而这种改动是毫无技术含量的改动。
就是傻瓜式的抓取dom，处理json数据，然后装进dom里面。这种局面亟待解决！
MV*
因为前端的C根本没有涉及复杂的业务逻辑，不像后端变化太多，就是数据变了后view怎么变，绑事件，抓dom树填入数据等，需求完全可以穷举出来。
vue充当中间的双向数据绑定，事件监听，即c的角色，只不过改为vm了而已。
前端view和model任意一方变了，另一方怎么变，需要程序员去指定规则，而这些规则vue都穷举出来，指定好了，即vue的语法。
用了vue就不要再去手动操作dom，别用原生js的getElementById，用了就剁手。
MVVM
M 负责数据存储
V 负责页面展示
VM 负责业务逻辑处理，对data处理后交给V展示，开发者无需手动编写代码指定一方动另一方怎么动，只需要按照vue的规则进行生命即可。
这样前端M可以由后端的接口传来数据，多个项目如果处理的是同一张表，那么完全可以复用。
V这个没办法复用，因为需求中页面会有不同，需要开发者自定义合理布局和数据展示。
C的角色现在由vue来充当，且换了个名字叫vm。
伪造
作为后端永远是不相信前端的，前端的一切都可以伪造出来！