漫谈前端架构技术选型

本文部分转自一些博客以及自己的汇总，仅做知识梳理归纳用，不作为个人版权，欢迎批评指正！

前面的话

有一个流传较广的笑话，一个人在stackoverflow中提了一个问题，如何使用javascript实现一个数字与另外一个数字相加。最高票回答是你应该使用jQuery插件，jQuery插件可以做任何事情。 历史总是在重演，以前是jQuery，现在可能是react或vue。不同的框架有不同的应用场景，杀鸡不要用牛刀。

多数产品的技术经理也会是后端出身的，往往对前端的认识还停留在Java Struts那个原始的MVC模型上，或者首先想到的就是GWT和JSF，这是从后端角度出发的一种视角。用这类思维方式做出来的产品，一般用户体验都不会很好。

从界面层上手的人群，他对用户体验这方面会把控得比较好，但通常缺架构意识，或者说是软件工程的意识。在界面层比较复杂的情况下，很可能会有失控的趋势。对整个系统结构的认知程度通常不够深入，也缺乏设计模式等方面的知识。

开发人员会有一些困惑：

  • 创建项目的时候，一般没有人作前端的技术选型

  • 拿到项目之后，没有直接可复制的基础版本

习惯于引用第三方组件

  • 赶功能，需要某个组件或者特效
  • 上网搜到一个合适的，加进来
  • 它还依赖一些别的库
  • 文件大还是次要的
  • 可能会产生冲突，样式也不一致

开发经理也会有一些困惑：

  • 协作过程感觉有问题

  • 前端人员写原始界面，包含静态界面和特效

  • 开发人员接着改，加逻辑

  • 发现有问题要返工了

  • 在谁的代码基础上继续改？如何合并？

为什么还有这么多人工环节？

  • 能自动单元测试吗？
  • 能自动发布打包吗？

用户会对这些事情感到烦恼：

  1. 长得丑：界面老土、 风格不一致
  2. 速度慢： 加载慢 、渲染慢 、执行慢

  3. 出错

     架构的本质是什么？其实也是一种管理。通常我们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。比如说，机器的部署属于运维的物理架构，SOA属于服务架构，那么，前端的架构指什么呢？

长期以来，前端所处的位置是比较偏应用层，而且是很薄的一层，而架构又要求深度和广度，所以之前在前端里面做架构，好比在小水塘里游泳，稍微扑腾两下就到处碰壁。但最近这几年来，前端的范围被大大拓展了，所以这一层逐渐变得大有可为。

怎样去理解架构呢？在早期的文字MUD游戏里，有这么一句话：“你感觉哪里不对，但是又说不上来。”在我们开发和使用软件系统的过程中，或多或少会遇到这样的感觉，有这种感觉就说明架构方面可能有些问题。

 在狭义的前端领域，架构要处理的很重要的事情是组件的集成。由于JavaScript本身缺乏命名空间这样的机制，多数框架都倾向于自己搞一套，所以这方面的碎片化是很严重的。

 比如说，在做某个功能的过程中，发现需要一个组件，时间来不及做，就到网上搜了个，加到代码里面，先运行起来再说。一不小心，等功能做完的时候，已经引入了无数种组件了，有很多代码是重叠的，可能有的还有冲突，外观也不一致。

 环顾四周的大型互联网公司，基本上都有自己的前端框架，比如阿里的Kissy和Arale，腾讯的JX，百度的Tangram，360的QWrap等，为什么？因为要整合别的框架，并且在此基础上发展适合自己的组件库，代价非常大，初期没办法的时候只能凑合，长期来说，所有代码都可控的意义非常重要。

  那么，是不是一套框架可以包打天下呢，这个真的很难。对于不同的产品形态，如果想要用一套框架去适应，有的会偏轻，有的又偏重，有的要兼容低端浏览器，有的又不要，很难取舍。

常见的前端产品形态包括：

  • 内容型Web站点： 侧重渲染方面的优化，前端逻辑比重小
  • 操作型B/S系统： 以数据和逻辑为中心，界面较规整
  • 内嵌Web的本地应用： 要处理缓存和一些本地接口，包括PC客户端和移动端

另外有Web游戏，因为跟我们的企业形态关系不大，而且也比较独特，所以不包含在内。这三种产品的前端框架要处理的事情显然是不太一样的，所以可以细分成2-3种项目模板，整理出对应的种子项目，供同类产品初始化用。

最近我们经常在前端领域听说两个词：全端、全栈。

全端的意思是，原来的只做在浏览器中运行的Web程序不够，还要做各种终端，包括iOS，Android等本地应用，甚至PC桌面应用。

为什么广义的前端应当包含本地应用呢？因为现在的本地应用，基于很多考虑，都变成了混合应用，也就是说，开发这个应用的技术，既包含原生的代码，也包含了嵌入的HTML5代码。这么一来，就造成了开发本地应用的人技能要求较广，能够根据产品的场景，合理选择每个功能应当使用的技术。

现在有一些PC端的混合应用开发技术，比如node-webkit和hex，前者的典型应用是Intel® XDK，后者的典型应用是有道词典，此外，豌豆荚的PC客户端也是采用类似技术的，也有一些产品是用的qt-webkit。这类技术可以方便做跨平台，极大减少开发工作量。

所以，我们可以看到，在很多公司，开发安卓、iOS应用的人员跟Web前端的处于同一个团队中，这很大程度上就是考虑到这种情况。

全栈的意思是，除了只做在浏览器中运行的代码，还写一些服务端的代码，这个需求又是从哪里来的呢？

这个需求其实来自优化。我们要优化一个系统的前端部分，有这么一些事情可以做：

  • HTML结构的优化，减少DOM树的层次等等
  • CSS渲染性能的优化，批量写入DOM变更之类
  • 资源文件的优化，比如小图片的合并，图像格式的处理，图标字体的使用等
  • JavaScript逻辑的优化，模块化，异步加载，性能优化
  • 加载字节量的优化，主要是分摊的策略
  • HTTP请求的优化

这里面，除了前三条，其他都可能跟后端有些关系，尤其是最后一条。但是前端的人没法去优化后端的东西，这是不同的协作环节，所以就很麻烦。

那么，如果有了全栈，这个问题可以怎么解决呢？

比如说，我们要做最原始的小文件合并，可以在服务器做一些配置，把多个合并成一个请求，比如天猫的某个url：

http://g.tbcdn.cn/kissy/k/1.4.1/??dom/base-min.js,event-min.js,event/dom/base-min.js,event/base-min.js,event/dom/touch-min.js,event/dom/shake-min.js,event/dom/focusin-min.js,event/custom-min.js,cookie-min.js?t=1.js

这个就很明显是多个文件合并而成的，9个小文件的请求，合并成了一个64k的文件请求。

这种简单的事情可以在静态代理服务器上配置出来，更复杂的就比较难了，需要一定的服务端逻辑。比如说，我们有多个ajax请求，请求不同的服务，每个请求的数据量都非常少，但因为请求数很多，可能会影响加载性能，如果能把它们在服务端就合并成一个就好了。但这个优化是前端发起的，传统模式下，他的职责范围有限，优化不到服务端去，而这多个服务很可能是跨产品模块的，想要合并，放在哪个后端团队都很怪异。

如果有这么一层NodeJS，这一层完全由前端程序员控制，他就可以在这个地方做这种合并，非常的合理。除此之外，我们常常会用到HTML模板，但使用它的最佳位置是随着产品的场景而不同的，可能某个地方在前端更好，可能某个地方在后端好些。到底放在哪合适，只有前端开发人员才会知道，如果前端开发人员不能参与一部分后端代码的开发，优化工作也还是做不彻底。有NodeJS之后会怎样呢，因为不管前端模板还是后端模板，都是JavaScript的，可以使用同一套库，这样在做调整的时候不会有代码迁移的烦恼，直接把模板换地方即可。

现在，也有很多业务场景有实时通信的需求，目前来说最合适的方案是Socket.io，它默认使用NodeJS来当服务端，这也是NodeJS的一个重要使用场景。

这样，前端开发人员也部分参与了运行在服务端的代码，他的工作范围从原先客户端浏览器，向后拓展了一个薄层，所以就有了全栈的称呼。至于说这个称呼还继续扩展，一个前端开发人员从视觉到交互到静态HTML到JavaScript包办的情况，这个就有些过头了。

以上这些，主要解决的都是代码层面的事情。另外有一个方面，也是需要关注，但却常常不能引起重视的，那就是前端的工程化问题。

早期为什么没有这些问题？因为那时候前端很简单，复杂度不高，现在整个很复杂了，就带来了很多管理问题。比如说整个系统的前端都组件化了之后，HTML会拆分成各种模板，JavaScript会拆分成各种模块，而CSS也通过LESS或者SASS这种方式，变成了一种编译式的语言。

这时候，我们考虑一个所谓的组件，它就比较麻烦了。它可能是一个或者多个HTML模板，加上一个或者多个JavaScript模块，再包含CSS中的一部分构成的，而前两者都可能有依赖项，三个部分也都要避免与其他组件的冲突。

这些东西都需要管理，并且提供一种比较好的方案去维护。在JavaScript被模块化之后，也可以通过单元测试来控制它们的质量，并且把这个过程自动化，每次版本有变更之前，保证它们最基本的正确性。最终，需要有一种自动化的发布机制，把这几类代码提取，打包合并，压缩，发布。

前端，是一种GUI软件

现如今前端可谓包罗万象，产品形态五花八门，涉猎极广，什么高大上的基础库/框架，拽炫酷的宣传页面，还有屌炸天的小游戏……不过这些一两个文件的小项目并非是前端技术的主要应用场景，更具商业价值的则是复杂的Web应用，它们功能完善，界面繁多，为用户提供了完整的产品体验，可能是新闻聚合网站，可能是在线购物平台，可能是社交网络，可能是金融信贷应用，可能是音乐互动社区，也可能是视频上传与分享平台……

从本质上讲，所有Web应用都是一种运行在网页浏览器中的软件，这些软件的图形用户界面（Graphical User Interface，简称GUI）即为前端。

如此复杂的Web应用，动辄几十上百人共同开发维护，其前端界面通常也颇具规模，工程量不亚于一般的传统GUI软件。

前端工程的三个阶段

现在的前端开发倒也并非一无所有，回顾一下曾经经历过或听闻过的项目，为了提升其前端开发效率和运行性能，前端团队的工程建设大致会经历三个阶段：

第一阶段：库/框架选型

前端工程建设的第一项任务就是根据项目特征进行技术选型。

基本上现在没有人完全从0开始做网站，哪怕是政府项目用个jquery都很正常吧，React/Vue.js等框架横空出世，解放了不少生产力，合理的技术选型可以为项目节省许多工程量这点毋庸置疑。

第二阶段：简单构建优化

选型之后基本上就可以开始敲码了，不过光解决开发效率还不够，必须要兼顾运行性能。前端工程进行到第二阶段会选型一种构建工具，对代码进行压缩，校验，之后再以页面为单位进行简单的资源合并。

第三阶段：JS/CSS模块化开发

分而治之是软件工程中的重要思想，是复杂系统开发和维护的基石，这点放在前端开发中同样适用。在解决了基本开发效率运行效率问题之后，前端团队开始思考维护效率，模块化是目前前端最流行的分治手段。

JS模块化方案很多，AMD/CommonJS/CMD/UMD/ES6 Module等，对应的框架和工具也一大堆；CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin特性支持下实现的。

虽然这些技术由来已久，在如今这个“言必及React”的时代略显落伍，但想想业界的绝大多数团队的工程化落后程度，放眼望去，毫不夸张的说，能达到第三阶段的前端团队已属于高端行列，基本具备了开发维护一般规模Web应用的能力。

然而，做到这些就够了么？Naive！

第四阶段:组件化开发与资源管理

前端是一种技术问题较少、工程问题较多的软件开发领域。

当我们要开发一款完整的Web应用时，前端将面临更多的工程问题，比如：

  • 大体量：多功能、多页面、多状态、多系统；
  • 大规模：多人甚至多团队合作开发；
  • 高性能：CDN部署、缓存控制、文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌 、HTTP 2.0服务端资源推送。

这些无疑是一系列严肃的系统工程问题。

前面讲的三个阶段虽然相比曾经“茹毛饮血”的时代进步不少，但用于支撑第四阶段的多人合作开发以及精细的性能优化似乎还欠缺点什么。

工程方案其实也可以小而美！只不过它的小而美不是指代码量，而是指“规则”。找到问题的根源，用最少最简单明了的规则制定出最容易遵守最容易理解的开发规范或工具，以提升开发效率和工程质量，这同样是小而美的典范！

我们只需做好两件事就能大幅提升前端开发效率，并且兼顾运行性能，那就是——组件化开发与资源管理。

前端相比其他软件开发，在基础架构上更加迫切的需要组件化开发和资源管理，而解决资源管理的方法其实一点也不复杂:

一个通用的资源表生成工具 + 基于表的资源加载框架

近几年来各种你听到过的各种资源加载优化策略大部分都可以在这样一套基础上实现，而这种优化对于业务来说是完全透明的，不需要重构的性能优化——这不正是我们一直所期盼的吗？

如何选型技术、如何定制规范、如何分治系统、如何优化性能、如何加载资源，当你从切图开始转变为思考这些问题的时候,你才能称得上“工程师”！

第一件事：组件化开发

分治的确是非常重要的工程优化手段。在我看来，前端作为一种GUI软件，光有JS/CSS的模块化还不够，对于UI组件的分治也有着同样迫切的需求：

如上图，前端组件化开发理念，简单解读一下：

  1. 页面上的每个独立的可视/可交互区域视为一个组件；
  2. 每个组件对应一个工程目录，组件所需的各种资源都在这个目录下就近维护；
  3. 由于组件具有独立性，因此组件与组件之间可以自由组合；
  4. 页面只不过是组件的容器，负责组合组件形成功能完整的界面；
  5. 当不需要某个组件，或者想要替换组件时，可以整个目录删除/替换。

其中第二项描述的就近维护原则，是我觉得最具工程价值的地方，它为前端开发提供了很好的分治策略，每个开发者都将清楚的知道，自己所开发维护的功能单元，其代码必然存在于对应的组件目录中，在那个目录下能找到有关这个功能单元的所有内部逻辑，样式也好，JS也好，页面结构也好，都在那里。

组件化开发具有较高的通用性，无论是前端渲染的单页面应用，还是后端模板渲染的多页面应用，组件化开发的概念都能适用。组件HTML部分根据业务选型的不同，可以是静态的HTML文件，可以是前端模板，也可以是后端模板：

不同的技术选型决定了不同的组件封装和调用策略。

基于这样的工程理念，我们很容易将系统以独立的组件为单元进行分工划分：

由于系统功能被分治到独立的模块或组件中，粒度比较精细，组织形式松散，开发者之间不会产生开发时序的依赖，大幅提升并行的开发效率，理论上允许随时加入新成员认领组件开发或维护工作，也更容易支持多个团队共同维护一个大型站点的开发。

结合前面提到的模块化开发，整个前端项目可以划分为这么几种开发概念：

名称 说明 举例
JS模块 独立的算法和数据单元 浏览器环境检测(detect)，网络请求(ajax)，应用配置(config)，DOM操作(dom)，工具函数(utils)，以及组件里的JS单元
CSS模块 独立的功能性样式单元 栅格系统(grid)，字体图标(icon-fonts)，动画样式(animate)，以及组件里的CSS单元
UI组件 独立的可视/可交互功能单元 页头(header)，页尾(footer)，导航栏(nav)，搜索框(search)
页面 前端这种GUI软件的界面状态，是UI组件的容器 首页(index)，列表页(list)，用户管理(user)
应用 整个项目或整个站点被称之为应用，由多个页面组成

以上5种开发概念以相对较少的规则组成了前端开发的基本工程结构，基于这些理念，我眼中的前端开发就成了这个样子：

示意图 描述
整个Web应用由页面组成
页面由组件组成
一个组件一个目录，资源就近维护
组件可组合， 组件的JS可依赖其他JS模块， CSS可依赖其他CSS单元

综合上面的描述，对于一般中小规模的项目，大致可以规划出这样的源码目录结构：

如果项目规模较大，涉及多个团队协作，还可以将具有相关业务功能的页面组织在一起，形成一个子系统，进一步将整个站点拆分出多个子系统来分配给不同团队维护。

以上架构设计历经许多不同公司不同业务场景的前端团队验证，收获了不错的口碑，是行之有效的前端工程分治方案。

第二件事：“智能”静态资源管理

上面提到的模块化/组件化开发，仅仅描述了一种开发理念，也可以认为是一种开发规范，倘若你认可这规范，对它的分治策略产生了共鸣，那我们就可以继续聊聊它的具体实现了。

很明显，模块化/组件化开发之后，我们最终要解决的，就是模块/组件加载的技术问题。然而前端与客户端GUI软件有一个很大的不同：

前端是一种远程部署，运行时增量下载的GUI软件

前端应用没有安装过程，其所需程序资源都部署在远程服务器，用户使用浏览器访问不同的页面来加载不同的资源，随着页面访问的增加，渐进式的将整个程序下载到本地运行，“增量下载”是前端在工程上有别于客户端GUI软件的根本原因。

上图展示了一款界面繁多功能丰富的应用，如果采用Web实现，相信也是不小的体量，如果用户第一次访问页面就强制其加载全站静态资源再展示，相信会有很多用户因为失去耐心而流失。根据“增量”的原则，我们应该精心规划每个页面的资源加载策略，使得用户无论访问哪个页面都能按需加载页面所需资源，没访问过的无需加载，访问过的可以缓存复用，最终带来流畅的应用体验。

这正是Web应用“免安装”的魅力所在。

由“增量”原则引申出的前端优化技巧几乎成为了性能优化的核心，有加载相关的按需加载、延迟加载、预加载、请求合并等策略；有缓存相关的浏览器缓存利用，缓存更新、缓存共享、非覆盖式发布等方案；还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。这些优化方案无不围绕着如何将增量原则做到极致而展开。

所以我觉得：

第四阶段前端开发最迫切需要做好的就是在基础架构中贯彻增量原则。

相信这种贯彻不会随着时间的推移而改变，在可预见的未来，无论在HTTP1.x还是HTTP2.0时代，无论在ES5亦或者ES6/7时代，无论是AMD/CommonJS/UMD亦或者ES6 module时代，无论端内技术如何变迁，我们都有足够充分的理由要做好前端程序资源的增量加载。

正如前面说到的，第三阶段前端工程缺少点什么呢？我觉得是在其基础架构中缺少这样一种“智能”的资源加载方案。没有这样的方案，很难将前端应用的规模发展到第四阶段，很难实现落地前面介绍的那种组件化开发方案，也很难让多方合作高效率的完成一项大型应用的开发，并保证其最终运行性能良好。在第四阶段，我们需要强大的工程化手段来管理”玩具般简单“的前端开发。

David Wei博士在当年的交流会上提到过一些关于Facebook的一些产品数据：

  • Facebook整站有10000+个静态资源；
  • 每个静态资源都有可能被翻译成超过100种语言版本；
  • 每种资源又会针对浏览器生成3种不同的版本；
  • 要针对不同带宽的用户做5种不同的打包方法；
  • 有3、4个不同的用户组，用于小批次体验新的产品功能；
  • 还要考虑不同的送达方法，可以直接送达，或者通过iframe的方式提升资源并行加载的速度；
  • 静态资源的压缩和非压缩状态可切换，用于调试和定位线上问题

这是一个状态爆炸的问题，将所有状态乘起来，整个网站的资源组合方式会达到几百万种之多（去重之后统计大概有300万种组合方式）。支撑这么大规模前端项目运行的底层架构正是魏博士在那次演讲中分享的Static Resource Management System(静态资源管理系统)，用以解决Facebook项目中有关前端工程的3D问题（Development，Deployment，Debugging）。

静态资源管理系统 = 资源表 + 资源加载框架

资源表是一份数据文件（比如JSON），是项目中所有静态资源（主要是JS和CSS）的构建信息记录，通过构建工具扫描项目源码生成，是一种k-v结构的数据，以每个资源的id为key，记录了资源的类别、部署路径、依赖关系、打包合并等内容，比如：

{
    "a.js": {
        "url": "/static/js/a.5f100fa.js",
        "dep": [ "b.js", "a.css" ]
    },
    "a.css": {
        "url": "/static/css/a.63cf374.css",
        "dep": [ "button.css" ]
    },
    "b.js": {
        "url": "/static/js/b.97193bf.js"
    },
    "button.css": {
        "url": "/static/css/button.de33108.css"
    }
}

而资源加载框架则提供一些资源引用的API，让开发者根据id来引用资源，替代静态的script/link标签来收集、去重、按需加载资源。调用这些接口时，框架通过查表来查找资源的各项信息，并递归查找其依赖的资源的信息，然后我们可以在这个过程中实现各种性能优化算法来“智能”加载资源。

根据业务场景的不同，加载框架可以在浏览器中用JS实现，也可以是后端模板引擎中用服务端语言实现，甚至二者的组合，不一而足。

这种设计很快被验证具有足够的灵活性，能够完美支撑不同团队不同技术规范下的性能优化需求，前面提到的按需加载、延迟加载、预加载、请求合并、文件指纹、CDN部署、Bigpipe、Quickling、BigRender、首屏CSS内嵌、HTTP 2.0服务端推送等等性能优化手段都可以很容易的在这种架构上实现，甚至可以根据性能日志自动进行优化（Facebook已实现）。

因为有了资源表，我们可以很方便的控制资源加载，通过各种手段在运行时计算页面的资源使用情况，从而获得最佳加载性能。无论是前端渲染的单页面应用，还是后端渲染的多页面应用，这种方法都同样适用。

此外，它还很巧妙的约束了构建工具的职责——只生成资源表。资源表是非常通用的数据结构，无论什么业务场景，其业务代码最终都可以被扫描为相同结构的表数据，并标记资源间的依赖关系，有了表之后我们只需根据不同的业务场景定制不同的资源加载框架就行了，从此彻底告别一个团队维护一套工具的时代！！！

如你所见，虽然彻底告别了一个团队一套工具的时代，但似乎又进入了一个团队一套框架的时代。其实还是有差别的，因为框架具有很大的灵活性，而且不那么黑盒，采用框架实现资源管理相比构建更容易调试、定位和升级变更。

深耕静态资源加载框架可以带来许多收益，而且有足够的灵活性和健壮性面向未来的技术变革！

框架与库

库(lib)具有以下三个特点：

1、是针对特定问题的解答，具有专业性；

2、不控制应用的流程

3、被动的被调用

框架(framework)具有以下三个特点：

1、具有控制反转(inverse of control)的功能

2、决定应用程序的生命周期

3、一般来说，集成了大量的库

由下图所示，框架会在特定的时间要求程序执行某段代码。框架决定了什么时候调用库，决定了什么时候要求代码去执行特定功能

而实际上，一个库有时也可以称之为框架，而库里面集成的方法称之为库

框架和库的区别不由实际大小决定，而由思考角度来决定。框架和库实际上可以统称为解决方案

解决方案

前端开发中的解决方案主要用于解决以下7个方面的问题：

1、DOM

2、Communication(通信)

3、Utililty(工具库)

4、Templating(模板集成)

5、Component(组件)

6、Routing(路由)

7、Architecture(架构)

【why】

为什么要使用外部的解决方案呢？

1、提高开发效率

2、可靠性高（浏览器兼容，测试覆盖）

3、配备优良的配套，如文档、DEMO及工具等

4、代码设计的更合理、更优雅

5、专业性高

如果问题过于简单，或者备选框架的质量和可靠性无法保证，再或者无法满足业务需求，则不应该选择外部的框架。如果团队中已经有相关的积累，就更不需要使用了

【how】

一般地，解决方案要实际开发中有以下3种使用方式：

1、开放式：基于外部模块系统，并自由组合

2、半开放式：基于一个定制的模块系统，内部外部解决方案共存

3、封闭式：深度定制的模块系统，很少需要引入外部模块

DOM

接下来，将针对解决方案中提到的7个问题进行分别介绍，首先是DOM

关于DOM，主要包括Selector(选择器)、Manipulation(DOM操作)、Event(事件)、Animation(动画)这四个部分

DOM相关的解决方案主要用于提供以下操作

1、提供便利的 DOM 查询、操作、移动等操作

2、提供事件绑定及事件代理支持

3、提供浏览器特性检测及 UserAgent 侦测

4、提供节点属性、样式、类名的操作

5、保证目标平台的跨浏览器支持

【常用方案】

常用的DOM解决方案有 jQuery、zepto.JS、MOOTOO.JS等

jQuery是曾经风靡一时的最流行的前端解决方案，jQuery特有的链式调用的方式简化了javascript的复杂操作，而且使人们不再需要关心兼容性，并提供了大量的实用方法

zepto是jQuery的精简版，针对移动端去除了大量jQuery的兼容代码，提供了简单的手势，部分API的实现方式不同

mootools源码清晰易懂，严格遵循Command-Query(命令-查询)的接口规范，没有诸如jQuery的两义性接口。还有一个不得不提的特点是，使用选择器获取的是DOM原生对象，而不是被包装过的对象。而它支持的诸多方法则是通过直接扩展DOM原生对象实现的，这也是它的争议所在

相比较而言，最稳妥的DOM解决方案是jQuery

【专业领域】

上面的解决方案用于解决DOM一般的通用问题。随着技术的发展，DOM的专业领域出现一些小而精致的解决方案

1、手势

Hammer.JS包括了常见手势封装（Tab、Hold、Transform、Swifp）并支持自定义扩展

2、局部滚动

iscroll.JS是移动端position:fix + overflow:scroll的救星

3、高级动画

Velocity.JS可以复杂动画序列实现，不仅局限于 DOM

4、视频播放

Video.JS类似原生 video 标签的使用方式，对低级浏览器使用 flash 播放器

通信

关于通信，主要包括XMLHttpRequest、Form、JSONP、Socket等

通信相关的解决方案主要用于提供以下操作

1、处理与服务器的请求与相应

2、预处理请求数据与响应数据 Error/Success 的判断封装

3、多类型请求，统一接口（XMLHttpRequest1/2、JSONP、iFrame）

4、处理浏览器兼容性

【常用方案】

除了jQuery等，其他常用的通信解决方案有Reqwest、qwest等

Reqwest支持JSONP，稳定性高，IE6+支持，CORS 跨域，Promise/A 支持

qwest代码少、支持XMLHttpRequest2、CORS 跨域、支持高级数据类型（ArrayBuffer、Blob、FormData）

【专业领域】

对于实时性要求较高的需求可以使用socket.io，它实时性高，支持二进制数据流，智能自动回退支持，且支持多种后端语言

工具包

工具包(Utililty)的主要职责包括以下：

1、提供 JavaScript 原生不提供的功能

2、包装原生方法，使其便于使用

3、异步队列及流程控制

【常用方案】

常用的工具包解决方案有es5-shim、es6-shim、underscore、Lodash等

上面提到的shim，也是经常听到的一个词，翻译过来是垫片的意思。对于es5、es6等标准包括的一些新方法，由于浏览器兼容性不高，所以无法直接使用它们。这时，就需要在保证实现与规范一致的基础上，来扩展原型方法，这种做法就叫做shim。好处在于，实际上就是在使用javascript的语法，但不用去考虑低版本浏览器的兼容性问题

es5-shim 提供 ES3 环境下的 ES5 支持

es6-shim 提供 ES5 环境下的 ES6支持

underscore 提供兼容 IE6+ 的扩展功能函数

Lodash是underscore 的高性能版本，方法多为 runtime 编译出来的

模板

模板主要包括三类：基于字符串的模板(String-based)、基于DOM的模板(DOM-based)、活动模板(Living Template)

1、基于字符串的模板(String-based)，解决方案包括(dustjs、hogan.js、dot.js)

原理如下：输入一段模板字符串，通过编译之后 ，生成一段Function，通过Function的render或类render函数渲染输入的数据data，输出模板字符串，字符串通过innerHTML或类似的方式渲染成最后的DOM结构。这类模板的问题在于通过字符串生成DOM之后就不再变化，如果在改变输入的数据data，需要重新render，重新生成一个全新的DOM结构，性能较差。但该模板可以在服务器端运行

2、基于DOM的模板(DOM-based)，解决方案包括(angularjs、vuejs、knockout)

原理如下：将输入的字符串模板通过innerHTML转换为一个无状态DOM树，然后遍历该节点树，去抓取关键属性或语句，来进行相关的绑定，进而变成了有状态的DOM树，最终导致DOM树会与数据模型model进行绑定。这类模板的特点是修改数据时，会使有状态的DOM树实时更新，运行时性能更好，也会保留 DOM 中的已有事件

3、活动模板(Living Template)，解决方案包括(RegularJS、RactiveJS、htmlbar)

原理如下：活动模板融合了字符串模板和DOM模板的技术，模板字符串string通过自定义的解析器DSL-based Parse解析成AST(抽象语法树)，通过遍历AST，使用createElement()、setAttribute()等原生DOM方法，生成DOM树，最终导致DOM树会与数据模型model进行绑定。由于其内部完全不使用innerHTML，所以安全性较高

组件

组件(Component)的主要职责包括以下：

1、提供基础的 CSS 支持

2、提供常见的组件，如slider、Modal等

3、提供声明式的调用方式（类似 Bootstrap）

【常用方案】

常用的组件解决方案有Bootstrap、Foundation等，两者具有移动端first的流式栅格系统，由sass组织，可定制UI；

Bootstrap封装了常用的组件，是目前最火的组件解决方案；

Foundation在国内知名度不高

NOTE：有存在不使用 jQuery 版本的 Bootstrap 可供使用。

路由

路由在单页系统中非常重要，主要职责如下

1、监听 URL 变化，并通知注册的模块

2、通过 JavaScript 进行主动跳转

3、历史管理

4、对目标浏览器的兼容性支持

无论什么框架，在完成配置之后，内部都有如下图所示的类似的路由表。

【常用方案】

常用的路由解决方案有page.JS、Director.JS、Stateman、crossroad.JS等

page.JS类似 Express.Router 的路由规则的前端路由库

Director.JS可以前后端使用同一套规则定义路由

Stateman处理深层复杂路由的独立路优库

crossroad.JS老牌路由库，API 功能较为繁琐

架构

所有的架构(architecture)都是一个目的，就是解耦。解耦有很多方式，可以通过事件、分层等

市面上，有很多架构模式，包括MVC、MVVM、MV*等

架构的职责主要包括以下：

1、提供一种范式帮助（强制）开发者进行模块解耦

2、视图与模型分离

3、容易进行单元测试

4、容易实现应用扩展

以MVVM为例，如下图所示。它包括Model(数据层或模型层)、View(视图层)、ViewModel(控制层)

Model(数据层或模型层)表示数据实体，它们用于记录应用程序的数据

View(视图层)用于展示界面，界面是数据定制的反映，它包含样式结构定义以及VM享有的声明式数据以及数据绑定

ViewModel(控制层)是View与Model的粘合，它通过绑定事件与View交互并可以调用Service处理数据持久化，也可以通过数据绑定将Model的变动反映到View中

它们的关系是：各部分之间的通信，都是双向的；View 与 Model 不发生联系，都通过 ViewModel 传递；View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而ViewModel非常厚，所有逻辑都部署在那里

【SPA】

要特点注意的是，MV* !== SPA(单页系统)

SPA应用程序的逻辑比较复杂，需要一种模式来进行解耦，但并不一定是MV*模式

技术／架构选型建言

选择前端框架应综合考虑框架本身与团队情况

选择框架要从两面看，一是看该框架的本领，二是看你们团队的能耐。

从框架的角度来看， 它的功能丰富不丰富、社区活跃度如何、国内社区活跃度如何（有的在国外流行，但国内只有初创公司或一些大公司的边缘项目在试水）、文档齐全与否、是否及时更新、测试覆盖率如何、上手难易度如何，都是我们考量点。不过能进我们视野内的外国框架，基本是身经百战，在造轮子兴盛的世界闯出来的领头羊。jQuery、Angular、KnockOut、Emberjs、Polymer、React、Vue、Backbone、Zepto，我们基本是围绕在这几个上面转了。当然还有更大型的东西，如EXT、 YUI、Dojo、EasyUI、Bootstrap，这是UI库层面的。但随着Web技术的不断发展，前端架构框架、UI框架、构建工具、CSS预处理等层出不穷，各有千秋。太多的框架在形成初期，都曾在web领域掀起过一场技术浪潮，可有些却仅仅是昙花一现，随着他们用户量的逐渐减少，社区也越来越不活跃。如：meteor、backbone、ember、knockout。

不禁感叹技术的更新换代来的太突然。为了追赶技术更新的脚步，保证技术实施的高性能，强兼容性，并且不会再短时间内被时代所遗弃。显然，我们第一步就是圈定时下最流行的框架与库作为评估对象，然后再根据自家公司的情况进行筛选。贵公司是建站公司，还是有自己产品的公司呢？如果是建站公司，页面不会复杂到哪里去，基本上jQuery+Bootstrap搞定，不要想得太多，就是它们。如果有自己产品， 要维护一大堆客户数据，要与客户打交道，不难想象存在非常复杂的CRM系统，按照中国人的特性，这东西只会越来越复杂，这就要慎重考虑了。这往往是持续十年的维护升级，我们需要看一下某框架是否有你们的产品那么长寿，这框架的升级更新是否频繁平缓。

以下为目前常见的主流技术参考，根据github关注度排名：

架构框架
框架名 技术支持 思想 针对性
React Facebook 虚拟dom，单项数据流 高效创建交互式组件
AngularJS Google 双向数据绑定，指令 结构化
Vue Evan You（尤雨溪） 轻量级AngularJS 更加简洁更易理解
构建工具
工具名 技术支持 思想 针对性
Webpack Tobias Koppers 模块化处理 Web模块化
Gulp / 基于流的自动化构建 Web流程化
Grunt / 自动化构建 自动化构建
CSS预处理
处理器名 技术支持 思想 易用性
Sass / 基于ruby具备编程模式 ***
Less / 动态化css *****

大工程应尽量避开谷歌产品

如果你的项目是一个跨度三年以上的大工程。我们需要使用更稳健成熟的技术方案，我们需要重点避开谷歌的产品，它的许多产品都是玩票性质，GWT、Closure、Darty就是前车之鉴。Polymer基于许多新技术构建，其中Object.observe()、 Custom Elements、HTML Imports、Shadow DOM、Model-Driven Views还远远没被标准化， 许多还是独家的，变数太大，因此才出现下图所示的悲剧。 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，avalon等国内优秀框架也值得考虑

如果你们的产品是后台系统，那么就有两个选择，使用EXT、EasyUI这些重大的UI库方案，其中EXT具有严重的排它性，它很难与其他前端解决方案并用。什么模块组织、打包、数据可视化，它都已经能全部帮你搞定。它文档齐备漂亮，入门难度中等，但它要求你的团队非常稳定，现在招一个专职EXT的前端是很难的。EasyUI是国内比较大牌的UI框架，虽然闭源，不过想扩展它不是难事。

此外，国内的淘宝Kissy， 网易Nej也不错。还有更轻量的方案：MVVM。MVVM最擅长做这些重交互的产品。举例说，为了对应复杂交互的Gird，jQuery社区开发出各种庞大巨物DataGrid、jqGrid、FlexiGrid，还不如MVVM几个循环绑定来得干脆利落，扩展性又好。Angular虽然有点坑，但如果你是从1.3用起，并且不鸟IE，它还是一个不错的选择，其活跃的社区为它带来无限的可能。KnockOut在.Net人群中非常流行，微软出品，前端MVVM框架的鼻祖，不过它需要对后端数据进行过多的加工，因为它本身是不支持对套嵌对象的绑定。avalon是比较适合国情的MVVM，有它专门兼容IE6的版本，易上手，性能高，视频教程多，出了问题可以抓得着作者，是它的几大卖点。

Kissy

是阿里集团自主开发的前端框架，目前在淘宝网、一淘网等阿里系网站上得到不少应用。Kissy 框架模仿 jQuery 编写了自己的内核 Kissy Core，用于对 DOM 的解析，Ajax 处理等。同时，有着丰富的控件，并实现了一些动画效果和特效。同样，在 Kissy 的控件中也可以看到 Bootstrap 等国外框架的影子。此外，Kissy abc 项目工具可以帮助用户实现自动化构建，并有很多扩展组件方便用户使用。
Qwrap
是百度有啊团队推出的 JavaScript 框架，现在被收入 360，被广泛应用与 360 产品中。Qwrap 综合 jQuery、Prototype、YUI 特点，对 JavaScript 进行了封装。但是，如果要把 Qwrap 算成一个前端开发框架还是有些牵强，因为除了 JavaScript 类库之外，Qwrap 基本乏善可陈，还处于发展阶段。
Tangram
是百度推出的另一个 JavaScript 框架，被广泛应用于百度系旗下的产品，与 Qwrap 类似，Tangram 也只能算是一个 JavaScript 框架，对 JavaScript 做了不少扩展，但是作为前端开发框架还是显得比较单薄。基于此，百度公司继续推出了两个基于 Tangram 的项目，Magic 和 Baidu Template。

重SEO产品，可考虑jQuery+Bootstrap+RequireJS组合

如果你们的产品是商场这样重演示类的产品，就对SEO有要求，MVVM就不适合了。目前也就Angular与avalon在搞后端渲染机制，但还不上了台面。这时jQuery+Bootstrap+RequireJS就非常好用。RequireJS的作用不单单是提供了一个按需加载机制，它还能让我们组织起更为庞大的代码。如果不用RequireJS，国内另一个选择是SeaJS，它的规范是CMD。此外还有CommonJS规范，但这无法直接运行于前端，需要借助fekit、FIS、Webpack这样的构建工具进行合并了。不管怎么说，你这时选用的框架必须存在AMD、CMD或CommonJS任一种加载规范，这方便你以后的横向扩展。至于插件，目前小插件们都趋向用UMD，它可以让AMD、CMD、CommonJS任一种加载器加载。

  • Bootstrap主要针对桌面端市场，Bootstrap3 提出移动优先，不过目前桌面端依然还是 Bootstrap 的主要目标市场。Bootstrap 主要基于 jQuery 进行 JavaScript 处理，支持 LESS 来做 CSS 的扩展。如果想要在 Bootstrap 框架中使用 Sass，则需要通过 Bootstrap-Sass项目增加兼容。Bootstrap 框架在布局、版式、控件、特效方面都非常让人满意，都预置了丰富的效果，极大方便了用户开发。在风格设置方面，还需要用户在下载时手动设置，可配置粒度非常细，相应也比较繁琐，不太直观，需要对 Bootstrap 非常熟悉配置起来才能得心应手。
  • jQuery UI是 jQuery 项目组中对桌面端的扩展，包括了丰富的控件和特效，与 jQuery 无缝兼容。同时，jQuery UI 中预置了多种风格供用户选择，避免了千篇一律。如果您对预置的风格不满意，还可以通过 jQuery UI 的可视化界面，自助对 jQuery UI 的显示效果进行配置，非常方便，够高端大气上档次。

移动端技术较混乱，需多管齐下

如果你们的产品是移动端，基本上是SPA架构了，因为这会减少等待，整页刷新与请求数。目前该领域非常混乱，不同于PC端，要兼容的浏览器多出N倍，并且为了性能，浏览器商乱砍功能或改变一些浏览器特性的行为，往往引发一些奇怪的BUG，目前社区正在整理这些坑与解药。但目前没有一个框架能够摆平所有问题，都需要多管齐下。我的见解是：

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……

其他参考点

1.框架自身：a. 是否成熟 b.架构和模式 c.生态系统

　React毫无疑问是现在最热门的前端框架，React目前属于快速发展阶段，是否成熟还需时间的考量。由于React的设计思想极其独特，属于革命性创新，性能出众，代码逻辑却非常简单。所以，越来越多的人开始关注和使用，认为它可能是将来Web开发的主流工具。

**Angular**提供了一系列健壮的功能，以及将代码隔离成模块的方法，这对提高可复用性、可维护性和可测试性都是非常有益的。它的核心功能包括MVC、模块化、自动双向数据绑定、语义化标签、依赖注入等等。Angular在从开源社区火起来就一直存在于人们的视线中，超前的设计理念，强大的生态系统，让他一直扬帆于web框架的浪潮中，稳步前行。

　Vue的作者是位中国人，虽然vue属于个人项目，但在简洁、轻量、快速、数据驱动、模块友好、组件化等方面是不输于AngularJs的，这是因为vue基本是在angular的设计思想上实现的库而非框架。说起vue不得不谈到它的小巧，小巧的一种好处就是可以让用户更自由的选择相应的解决方案，在配合其他库方面它给了用户更大的空间。Vue虽然小巧，但是“麻雀虽小五脏俱全”，在构建大型应用的时候也是得心应手。并且近几年来vue得到了国内外多数公司的认可，社区生态系统也日趋完善。

2.项目契合：a.是否能满足需求 b.是否适合项目

　　React对于数据逻辑方面需要操心的更少了，可以直接全量赋值。通过虚拟dom，进行dom局部更新这一点很吸引人，省去前端对数据逻辑的判断和操作。react目前我感觉优势在于native相关，未来大有可玩。单纯的web项目的话，学习成本相对vue来说还是很高的，react只是view还需要配合其他类flux的框架开发。最后，使用场景上来说：React配合严格的Flux架构，适合超大规模多人协作的复杂项目。

　　Angular允许你构建功能强大且易于理解和维护的机构化应用程序，angular是一个为动态web应用设计的结构化框架，提供给大家一种新的开发应用方式，这种方式可以让你扩展HTML的语法，以弥补在构建动态WEB应用时静态语言所体现的不足。Angular的结构化就是讲究责任分离，这样代码才好理解，维护和测试。

　　Vue体积小，接口灵活，侵入性好，可用于页面的一部分，而不是整个页面。扩展性好，源码规范简洁。更适合手机端的WEB开发，是声明式开发，性能高于angular，体积小很多。社区生态正在逐步完善，用的人相对较少，网上的资料也不多，出了问题的解决成本高。

决策目的

基于参考点及项目需求择优以上web端常用工具及架构框架，UI框架可根据兼容性、易用性、及熟练程度选择。

可选方案（主流web框架比较）

编号 框架名 构建工具 Css预处理器 评分
1 Angular Gulp/webpack less *****
2 React+flux Webpack/gulp+webpack less ***
3 Vue Gulp/webpack less **

结论

vue相比于Angular.js，Vue.js提供了更加简洁、更易于理解的API，使得我们能够快速地上手并使用Vue.js。但是从另一方面来看它却显得毫无新意，甚至有点苍白无力。AngularJS非常结构化，大而全，虽然臃肿，但是成熟稳定。React在我看来并不是一个框架，而是一种设计思想。并且它的这种思想非常

空前，甚至可以移植到任何一个框架上，所以react和以上框架并无可比性，react所引领和激发的一系列开发思想，在React生态圈颇有些百家争鸣的感觉，各种新玩法层出不穷，所谓任重而道远，我认为对于react还是静观其变才好。

这里不过多评价前端自动化构建工具和css预处理器，因为这些仅仅是工具，完全可以不使用或者选择性搭配使用。只要能帮助我们简明、清晰、快速的搭建web应用就足够了。以上提到的3个框架，有种三分天下的感觉。

没有万能的框架，更没有万能的技术，最适合的才是最好的

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

results matching ""

    No results matching ""