转: 如何挑选适合的前端框架

from:　　https://github.com/RubyLouvre/agate/issues/8

如何挑选适合的前端框架

最近几年，前端技术迅猛发展，差很少每一年都会冒出一款主流的框架。 每次新开业务线或启动新项目时，是第一件事就是纠结：使用什么框架，重造什么轮子？我很高兴应CSDN的邀请谈个人见解。

在五六年，移动端尚未兴起，咱们没有什么选择，就是jQuery。有人会说，jQuery只是类库，不是框架;但那时前端业务尚未像今天这么繁重，本来是后端干的事，所有挪到前端来，由于光是jQuery就能够包打天下。jQuery不够用，还有成千上万的jQuery的插件呢。因而问题就是这样一一衍生出来了，一个页面太多jQuery插件了，请求数太多了，因而咱们得打包。打包须要咱们对插件有规划。因而这需求在社区上逐渐造成了某些规则，其中最出名的是AMD规范，体现上requirejs这个加载库上。

requirejs是前端技术发展上的一个分水岭。javascript在es6以前一直没有本身的加载机制，requirejs的出现意味着前端能够向更大规模发展。之后我说的技术选型，一个很是重要的甄选点， 就是 是否存在加载器机制或符合某个模块规范。

回到原来的话题，选择框架要从两面看，一是看该框架的本领，二是看大家团队的能耐。

从框架的角度来看， 它的功能丰富不丰富，社区活跃度如何，国内社区活跃度如何（有的在国外流行，但国内只有初创公司或一些大公司的边缘项目在试水），文档齐全吗，及时更新吗，测试覆盖率如何，上手难度如何，都是咱们考量点。不过能进咱们视野内的外国框架，基本是身经百战，在造轮子兴盛的世界闯出来的领头羊。jQuery， angular， knockout， emberjs， polymer， react， backbone， zepto，咱们基本是围绕在这几个上面转了。固然还有更大型的东西， EXT， YUI， dojo， easyui， bootstrap， 这是UI库层面的。

下面是2012年外国对当时流行12个javascript MVC框架的纯技术评估:

显然，咱们第一步就是圈定时下最流行的框架与库，做为评估对象，而后再根据自家公司的状况进行筛选。贵公司是建站公司，仍是有本身产品的公司呢？若是是建站公司，页面不会复杂到哪里去，基本上jQuery+bootstrap 搞定，不要想得太多，就是它们。若是有本身产品， 要维护一大堆客户数据要与客户打交道，不难想象是存在很是复杂的CRM系统，按照中国人的特性，这东西只会愈来愈复杂，这就要慎重考虑了。这每每是持续十年的维护升级，咱们须要看一下这框架是否有大家的产品那么长寿，这框架的升级更新是否频繁平缓。

若是你的项目是一个跨度三年以上的大工程，用《人月神话》的术语来讲，90%就是个焦油坑。咱们须要使用更稳键成熟的技术方案，咱们须要重点避开谷歌的产品，它的许多产品都是玩票性质， GWT、Closure、Darty就是前车可鉴。polymer是基于许多新技术构建(http://www.csdn.net/article/2013-05-27/2815450-google-polymer)，其中Object。observe()， Custom Elements， HTML Imports，Shadow DOM， Model-Driven Views是远远没被标准化， 许多仍是独家的， 变数太大，所以才出现以下的悲剧http://weibo.com/1712131295/CfB7X336J?type=comment#_rnd1430880258836。 angular不是我黑它， 这东西也喜欢断崖式升级， 它在1.08时兼容IE6-8， 1.2时须要打补丁兼容旧式IE， 1.3摒弃对旧式IE的兼容，直接在源码中删除全部兼容代码，所以全部补丁方案都无力回天，而且不支持全局Ctrl函数，许多模块须要独立引用，1.4不向下支持动画模块， 2.0由at改为ts构建，因为使用Object.observe，所以不支持IE6-11，chrome30-……

若是大家的产品是后台系统，那么就有两个选择，使用EXT， easyui这些重大的UI库方案，其中EXT具备严重的排它性，它很难与其余前端解决方案并用。什么模块组织，打包，数据可视化，它都已经所有帮你搞定。它文档齐备漂亮， 入门难度中等， 但它要求你的团队很是稳定，如今招一个专职EXT的前端是很难的。easyui是国内比较大牌的UI框架，虽然闭源，不过想扩展它不是难事。此外，国内的淘宝kissy， 网易nej也不错。还有更轻量的方案，MVVM。MVVM最擅长作这些重交互的产品。举例说，为了对应复杂交互的gird，jquery社区开发出各类庞大巨物 datagrid， jqgrid， flexigrid，还不如MVVM几个循环绑定来个干脆利落，扩展性又好。目前，knockout， emberjs， angular与我写的avalon就是这一类框架。angular虽然有点坑，但若是你是从1.3用起，而且不鸟IE，它仍是一个不错的选择，其活跃的社区为它带来无限的可能。knockout在。net人群中很是流行，微软出品，前端MVVM框架的鼻祖，不过它须要对后端数据进行过多的加工，由于它自己是不支持对套嵌对象的绑定。emberjs没有一个好干爹，但有一个好亲爹，做者Yehuda Katz是jQuery， rails， Sproutecore， Merb， Handlebars这些著名框架的核心成员， 虎父无犬子，emberjs如今仍是国外的第二大MVVM框架。avalon是比较适合国情的MVVM，有它专门兼容IE6的版本，易上手，性能高，视频教程多，出了问题能够抓得着做者，是它的几大卖点。

若是大家的产品是商场这样重演示类的产品，就对SEO有要求，MVVM就不适合了。目前也就angular与avalon在搞后端渲染机制，但还不上了台面。这时jQuery+bootstrap+requirejs就很是好用。requirejs的做用不仅仅是提供了一个按需加载机制,它还能让咱们组织起更为庞大的代码。若是不用requirejs，国内另外一个选择是seajs，它的规范是CMD。此外还有commonjs规范， 但这没法直接运行于前端，须要借助fekit， fis， webpack这样的构建工具进行合并了。无论怎么说，你这时选用的框架必须存在AMD，CMD或commonjs任一种加载规范，这方便你之后的横向扩展。至于插件，目前小插件们都趋向用UMD（https://github.com/umdjs/umd ），它可让AMD，CMD，commonjs任一种加载器加载。

若是大家的产品是移动端，基本上是SPA架构了，由于这会减小等待，整页刷新与请求数。目前该领域很是混乱了，不一样于PC端，这要兼容的浏览器是多出N倍，而且为了性能，浏览器商乱砍功能或改变一些浏览器特性的行为，这每每引起一些奇怪的BUG，目前社区正在整理这些坑与解药（https://github.com/jtyjty99999/mobileTech ）。但目前没有一个框架可以摆平全部问题，都须要多管齐下。个人看法是

requirejs(按需加载，移动端上能够不打包，善用304缓存，腾讯搞出一个更牛叉的增量更新加载器MT，也能够试试) + backbone（组织代码与路由管理） + zepto（轻量DOM操做） + fastclick.js(点击穿透与延迟处理) + hammer.js（各类触屏事件） + iscroll5.js(滚动条处理) + Animate.css(CSS3动画) + Enquire.js（处理响应式布局）。

可见移动端每一个部件都烂到蕊了，每一个部件都须要专门的工具进行修复。移动端是很是注重体验的，每个小角落都存在着各类动画，但浏览器或自带的webview都不好劲，因而native与hybird的话题才一直这么火。有的人说，既然dom是最吃性能，那么就干脆用canvas来代替吧（http://zhuanlan.zhihu.com/FrontendMagazine/19967854与http://www.ruanyifeng.com/blog/2015/02/future-of-dom.html ）。facebook也推出本身相似的方案， react native，本身实现一套GUI，不过编写语言是javascript。它是使用本身原来的超高性能轮子react实现的。这或者是一条道路。但优缺点也明显，正如angular浓浓的java风，react是在逻辑插入大段标签语言（jsx）。同时react的排它性也很是强，很难与其余库搭配使用。同时，咱们能够看到，出自jQuery名门的jQuery mobile并无入围，那个性能太糟了，连sencha touch。上面说的只是核心库， 尚未搬出UI库呢。号称mobile first的UI库不在少数，因为无视IE，能够大胆使用CSS3。目前比较出彩的有，foundation，semantic，refill， ratchet。若是只是想运行在平板上，性能问题就不会那么拮据了，咱们还能够试试inoic， sencha touch， Kendo UI Mobile……

基本上，针对每一个平台，我都列出一些主流框架了，但不意味着大家都能驾驭得住。小马过马，老牛没过膝，松鼠淹个半死，就是这么回事。创业公司喜欢新框架，这与他们拿得起高薪招一两个前端牛人而致，基本上全部页面就是他们干的，所以用angular或ember都没区别。小公司则当心，人员流失大，jQuery+requirejs是万金油。大公司则基本上有本身的技术沉淀，换言之，应该有本身的前端框架，除非那东西很陈旧，不建议再造轮子。大公司建议是搞本身的技术委员会，根据本身的人员配置来挑选的框架。有句话说得好，不求最好，但求最合适．有些框架就属于牛逼人手里牛逼闪闪，二逼人手里一团乱麻的。对于某些成长特别快的中等公司来讲，这点最需防范 ，牛人是有的，但做战的主体70%都是刚培训出来的实习生，难上手，中文文档不全的框架就必须过滤掉。我也不排除造轮子的可能性，毕竟有些公司就是人才辈出，能推出一些靠谱的开源产品来造福社区。

但不管咱们选择什么框架或决定本身动手造轮子，都勿忘初心，技术必须让咱们工做生活更为轻松愉快——咱们只选择咱们能驾驭住的框架，咱们不能保证它在一年后会过期落后，但至少不会变成绊脚石。套用亚当·斯密的话(税收是一种必要的恶)来讲，框架是一种必要的恶，它是强约束的，所以必须慎重选择。