说起前端框架，我个人主张有框架不如无框架，这个观点要先从框架和库的区别说起。
我所理解的库，解决的是代码或是模块级别的复用或者对复杂度的封装问题；而框架，更多的是对模式级别的复用和对程序组织的规范，这里的模式是指比如 MVC，为了实现 M 和 V 的解耦，通过 IOC 或是 PubSub 等手段，把丑陋的耦合由经常变化的业务代码转移到不经常变化的框架内部消化。
对于前端来说，在 WebApp 概念兴起前，很少能看到所谓的框架，更多的是类似于 jQuery、YUI 的库，因为前端的一路下来的发展历程和开发方式的特殊性决定了很难有什么通用的模式能满足多样化前端的开发需要。如果一定要说，也就是近些年伴随着 SPA（Single-page application）概念兴起而出现的所谓前端 MVC 的一系列衍生模式，但是即便如此，光靠一个框架还是解决不了什么问题。
这里要重点说一下 SPA 这个随着 AJAX 技术火起来的概念，SPA 的好处有哪些相信不用多说，网上一搜一大堆，接近原生应用的表现、和 HTML5 技术发展方向向契合等等。SPA 的出现让前端变得越来越重，代码组织、逻辑解耦等后端常常面对的问题也开始在前端出现，人们也开始在前端引入 MVC 去应对这样一些问题，确实很有成效。但是前端变重所面临的问题就仅仅是 JavaScript 层面的 MVC 能解决的吗？
我们来看前端开发的特点，HTML + CSS + JavaScript 三种不同类型的语言相互配合实现需求；再来看页面加载的特点，先加载 HTML，再有策略的加载 CSS 和 JS，碰到对性能要求较高的场景还要考虑分模块按需加载，在大型 SPA 中还有可能要把页面拆成一个个组件，每个组件又包含模板、样式、脚本，页面拆分成组件的策略是什么，组件的按需加载策略又如何，这些显然不是 MVC 框架擅长解决的问题，这也是 AMD/CMD 等模块机制提供者和加载器流行起来的原因。
近两年开始流行大前端的概念，我的理解这里的大前端说的就是前端的工程化，前端开发的工程特点开始和后端开发越来越像，这也给我们提供了更多的思路，框架解决不了的问题，是不是能像后端一样靠工具解决，过程中的模式（指类似的、重复性的工作）是否可以借助于持续集成工具实现自动化。回到刚才说到的前端组件化问题，代码在开发环境应该对开发人员友好，开发人员可以分工编写不同的组件，每个组件的模板、样式、脚本代码可以分别写在独立的文件中，分目录组织；代码在发布环境应该对用户友好，组件的代码应该根据策略打包成一个或多个文件并进行压缩，便于按需加载和节省流量。而这些正应该是工具要做的。
说到这里，其实框架对于程序组织的规范性上面的作用已经不明显，为了更灵活的模块化，不如不去用框架，把自定义事件的能力封装成模块，PubSub 模式解耦形成约定，用约定和书面规范代替框架去约束程序的组织，让开发人员直面框架的本质，充分发挥人的能动性，相信这才是更利于人才成长的实践方式。
最后提一下前端基础架构方面的一些思考，不要放大框架的作用，随着前端的成熟，工程化的特点会越来越明显，框架、库、工具、过程规范、文档这些东西的发展缺一不可，只有系统的结合才能发挥出技术的最大效能，在这样的平台上去实践、去积累，人才能更全面的发展。
欢迎微博 @Hinc 讨论。
P.S. 上述观点有一定的适用场景，对于比如 HTML5 游戏之类的场景不太适用，请不要断章取义、生搬硬套。
