JavaScript 框架对于前端来说就像是，八倍镜对于98K一样重要，成为了前端开发事半功倍，不可或缺的一部分。但是很少有人思考过，我们为什么使用框架？仅仅是因为代码量减少吗？
很多前端开发者使用框架是因为：
“ 现在某某框架很火，我也要学习使用一下。”
“ 这个框架 UI 库很多，漂亮，跟公司设计很相似。”
“ 这个框架有很多插件，引入调用一下就行，省了我很多代码量。”
“ 公司项目碰巧很适合做单页面应用。”
“ 我喜欢用数据绑定。”
上面的几个答案确实是框架可以解决的问题，但仅仅是因为这些吗？因为某一个问题，就引入一个庞大的框架，绝不应该如此。
为什么使用框架？
近年来，因为互联网的崛起，web 业务也越来越复杂和多元化，一个web项目也不是像以前那样写几个网页拼起来，加几个特效 duang 一下就成了。项目复杂了，出现的问题也就多了。
前后端分离
在前后分离概念出现之前，大部分 web 项目都是后端人员又当爹又当妈的，前后端一起搞，导致质量和效率不是很好。而且对个人的发展也有影响，一个人你什么都会，也意味着你什么都不精，毕竟天才还是少数的。这也是社会趋势影响，大公司招聘，一般也都是需要某一方面很有研究的专才。
在互联网的洪流下，以前的那种方式越来越跟不上节奏，所以前后端分离应运而生。
前后端分离后，前端的任务也变得重要起来，web前端开发慢慢趋于规范。
但是在 jQuery 称霸的时代里，并不能满足前端开发人员的需求。也慢慢暴露出了很多不好解决的问题：外部js引用太多，复用性低，开发周期太长，性能低，效率低等等，这些 jQuery 不好解决或者说解决不了的问题，也成为了前端开发的趋势。
使用框架解决了哪些问题
重复引用外部js
在以前使用jQuery开发时，当项目越来越复杂和庞大的时候，可能会用到各种各样的第三方插件，而且不只是一个页面使用，所以会出现每个页面都要引用一遍相同的js文件，冗余大的问题。
这样不仅会使页面代码变得杂乱，而且会影响页面的打开速度，万一以后需要变更一下js文件的路径，还要一个一个去修改，对后期的维护也是很大的负担。
使用框架开发时（例如Vue），一般都会搭配构建工具使用（例如webpack），整个项目运行时会有一个入口文件，当你有多个组件都会用到某个文件或插件时，仅仅在这个入口文件引入一次，就可以在你所有组件中使用这个插件的方法，可以说是一劳永逸。就算后期文件位置有所变动，也只是修改入口文件中的引用路径就可以了。
组件化
组件是前端框架里非常强大的功能之一，它可以扩展你的HTML，封装可以重用的代码块，比如你的轮播图、tab切换、页面头部、页面底部等等。
这种独立的组件具有了结构（html），表现（css）和行为（js）完整的功能，很大程度的节省了代码量，提高了代码的复用性。根据不同的需求定制你自己的组件，在需要的页面引用即可。在团队合作开发中，相对独立开发不同的组件，效率上也有很大的提升。
开发周期长
jQuery开发时，需要频繁的操作DOM，几乎任何动态效果都需要去选择DOM来进行相应的操作，这使开发变得麻烦起来，很多的时间都用到了操作DOM上，项目的开发周期自然被延长。
使用框架开发，框架中封装许多的频繁使用的功能，例如Angular中的指令，指令功能有数据绑定，表单验证，数据格式化等等。这时前端的重点只需要放在数据逻辑部分，而不需要花费很大的精力去操作DOM完成功能，从而加快项目进度。
性能
很多DOM操作会引起回流和重绘，对于jQuery来说，大量的操作DOM虽然方便，但是很浪费页面性能。
框架和jQuery虽然都会操作DOM，但是框架吧大量的DOM进行了处理和优化（例如Vue的虚拟DOM），通过数据驱动，就能渲染出DOM，大大提升了性能。
第二篇：
前端框架到底帮你解决了什么问题？
这段文字的起因是看到时间线上有篇文章说“前端书籍都是垃圾”（顺便说一句，其实这篇文章的作者不是瞎唬烂，他提出了一个深刻的问题，虽然他的思考结论是错的）。垃圾肯定谈不上，但我觉得市面上大部分前端的书籍也好，文章也好，甚至框架官方文档也好，确实都没有解释清楚一个问题：前端框架到底帮你解决了什么问题？
- 是数据驱动问题吗？不是，数据驱动我们自己用手敲也能敲的很优雅。
- 是事件监听问题吗？也不是，事件监听用事件代理就可以写出很好的代码。
- 是所谓的“组件化开发”吗？更不是，组件化开发是思想，有没有框架，组件化都是必须的。
那么前端框架到底解决了什么问题？
框架其实就解决了一个问题——使用声明式语法，描述组件对象的嵌套关系，并自动生成与dom对象的对应关系。
自己敲过框架轮子的人一定明白我在说什么——你在自己写框架的时候，最难处理的不是数据驱动，observable库有的是，也不是事件监听，那玩意儿jquery已经做的很好了，更不是模板语法，谁还写不出个模板转render的函数？真正有点麻烦的问题是：
- dom对象以及他们的从属（同时是传递关系）关系，是通过html自动生成的，然而当你把“组件”抽象为js对象，你怎么能实现子组件的自动创建，自动销毁，自动数据传递，自动render，自动事件监听（不一定是dom事件）？
- 怎么把js组件对象存在它应该在的地方（我的标题图截得是preact源码解决这个问题的部分，preact的子组件实例，是存在dom节点上的），并且rerender的时候能把js组件对象和dom节点对应起来？
- 什么时候需要new，什么时候复用原来的组件？
- 组件重渲染之后，怎么commit到dom上？
这套机制，才是前端框架真正替你省力的“脏活”，因为不如此，你的组件根本集成不起来，“组件化开发”、“数据驱动”也就无从谈起。至于框架对外提供的那些特性和语法糖，其实都见仁见智，有人喜欢有人不喜欢。但是我前面说的那些脏活，才是一个框架之所以是一个框架的理由。
关于这套机制，类angular框架和类react框架分别讲了两个故事——
- angular讲的故事是“模板编译为能精细感知model变化事件的dom-commiter”。
- react讲的故事是“model怎么变不重要，我只要model当前状态，我有办法给你patch到dom上”。
表面上看起来是很不一样的，但是本质上都是做同一件事——
你在模板里面也好，jsx里面也好，使用组件时写的的都是组件的类型，然而实际render的时候，框架帮你自动创建了组件实例。第二次render的时候，框架又帮你做了两件事，第一件事是，帮你找到应被复用的组件实例，指挥他重新render一遍，第二件事是，帮你把render的结果commit到正确dom节点上。
所以“xxx框架比yyy框架如何”这种问题，压根就不是问题——反正他们干的都是同一件事情，内部实现的不同对你来说也不太重要，纠结什么框架好有什么用呢？反正在真正比较复杂的项目中，框架的角色无非就是个view层，玩不出什么花样来。工程上那个框架最合心意用哪个就好。
来源：CSDN
作者：小牛同学_
链接：https://blog.csdn.net/ChickenBro_/article/details/104223360