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

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

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

requirejs

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

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

下面是2012年外国对当时流行12个javascript MVC框架的纯技术评估:
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/19967854http://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%都是刚培训出来的实习生,难上手,中文文档不全的框架就必须过滤掉。我也不排除造轮子的可能性,毕竟有些公司就是人才济济,能推出一些靠谱的开源产品来造福社区。

但无论我们选择什么框架或决定自己动手造轮子,都勿忘初心,技术必须让我们工作生活更为轻松愉快——我们只选择我们能驾驭住的框架,我们不能保证它在一年后会过时落后,但至少不会变成绊脚石。套用亚当·斯密的话(税收是一种必要的恶)来说,框架是一种必要的恶,它是强约束的,因此必须慎重选择。


来源


转载请注明出处(http://blog.pcwuyu.com/2016/662.html)