关于前端框架的一些观点

http://hinc.me/2013/04/01/front-end-framework/

提及前端框架，我我的主张有框架不如无框架，这个观点要先从框架和库的区别提及。

我所理解的库，解决的是代码或是模块级别的复用或者对复杂度的封装问题；而框架，更多的是对模式级别的复用和对程序组织的规范，这里的模式是指好比 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 模式解耦造成约定，用约定和书面规范代替框架去约束程序的组织，让开发人员直面框架的本质，充分发挥人的能动性，相信这才是更利于人才成长的实践方式。

最后提一下前端基础架构方面的一些思考，不要放大框架的做用，随着前端的成熟，工程化的特色会愈来愈明显，框架、库、工具、过程规范、文档这些东西的发展缺一不可，只有系统的结合才能发挥出技术的最大效能，在这样的平台上去实践、去积累，人才能更全面的发展。