为何须要本身实现前端框架

前端对框架(库)的大小更敏感

 

    前端内容的渲染和交互效果的实现若是依赖JS框架(库)，须要先将这些框架(库)下载到客户端，此时框架(库)的大小将直接影响到前端的首屏渲染速度。框架(库)越小，加载的速度就越快，而随着功能的愈来愈全，框架(库)必然会愈来愈大，要保证性能，须要制定加载策略。

 

便于制定加载策略

 

    解决框架(库)变大的常见加载策略是将框架分为核心部分和扩展部分，核心部分在首屏渲染前必须下载完成，而且这部分的加载文件尽量的少和小，扩展部分则能够模块化方式来懒加载。

    

    核心部分的JS在发布时，可对文件合并，数量尽量少，单个文件在gzip压缩后最好不要超过20K。核心部分能够是实现“JS语言扩展(面向对象)，DOM操做API，数据交互方法(ajax)，导航策略，模块化底层实现，事件底层实现，模版解析”等。扩展部分通常是一些可异步加载的UI组件，例如：输入控件、弹出窗、动画API、文件上传及预览、图表控件、富文本编辑器等。

 

    上面的实现模式，在主流的JS框架(库)中，有三类选择：一类是以ExtJS为表明的大而全的框架(库)，这类框架虽然功能知足，但每每没法拆分为核心部分和扩展部分来加载，所以基本不予考虑；一类是相对轻量的YUI三、Dojo等框架(库)；一类是近来流行的前端MV*系列Backbone、Ember、Angular，这类在充当核心部分时，还须要组合Underscore、RequireJS，jQuery等第三方库。

 

    后面两类能够知足要求，但我的以为不是完美的方案，由于在开发实际产品时，将这两类做为核心部分时，每每里面有不少是不须要的，而还有些须要本身来额外补充近来，能够是本身开发，也能够集成第三方的实现。而核心部分框架(库)若是是本身实现，则能够保证在功能完整的状况下，很少出其它的东西，加载的JS能够控制到最小，并且代码风格也统一。

 

便于扩展

    

    前端代码与用户的交互直接相关，而交互的设计变化和不肯定性很是大，现成的第三方实现每每难以直接利用，须要改造。有时改造第三方的框架，先要很是熟悉框架，当这个框架比较复杂时，这样的工做量和难度就大大加大了。而自实现的框架(库)则能够根据须要任意扩展，能够根据需求制定对应的规范和API。

 

便于统一开发规范

 

    不一样的JS框架(库)，调用方式每每也不一样（模块化规范，DOM操做API，面向对象语法糖等）。在使用第三方框架(库)，特别是组合多个第三方框架(库)时，若是要实现产品代码书写规范的一致，须要实现本身代码来包装第三方框架(库)，达到调用接口的书写风格一致。本身实现的框架(库)则能够免去这一步骤。

 

减小升级带来的风险

 

    有些第三方框架(库)在版本升级后，API、浏览器兼容性支持度、实现理念可能会发生变化。例如：ExtJs3和ExtJs4的差异就很是大，若是产品急于ExtJs3开发，想升级到4几乎就要作产品重构了，并且ExtJs4再也不支持低版本IE浏览器。当组合使用多个框架(库)时，其中一个升级也可能会引发彼此之间的兼容性问题。还有可能出现引用的框架(库)在升级前，在产品中没有出现问题，升级后，由于框架(库)的理念变化，致使再也不适合在当前产品中使用，不然会出现性能问题。

 

什么状况适合使用第三方实现

 

    (1) 非“核心库、影响到产品集成与结构的部分、经常使用UI组件”

 

    为了保证性能和扩展的方便，核心包和经常使用的UI组件能够选择自实现。由于难以找到一个第三方框架能够包含全部的核心包所需的功能，这样核心包就会由多个第三方包组合加上部分的自行实现。在组合第三包时，每每会带来不少不须要的代码，这样就不能保证核心包的精简。UI组件每每由于须要依赖于一些核心库(框架)，经常使用的UI组件本身实现，一来是能够依赖本身的核心库(框架)，减小大小，一来是这些经常使用UI组件每每会在系统的中大量使用，对页面的的视觉等待加载时间会有大的影响，或者是有深刻的个性化需求，本身实现量身打造，而且方便扩展。

 

    (2) 复杂的UI组件

     

    复杂的UI组件，例如：富文本编辑器，日历，动画效果，图表等。这些不会影响产品的架构，技术方向和性能，而实现又比较复杂，当产品须要时，能够选择合适的第三方实现，经过模块化方式异步加载。若是有个性化需求，而其又没有扩展接口，则可尝试修改其源码。

 

    (3) 文件小、依赖少、功能单一

 

    不少人会将本身些的一些框架(库)放到github上开源。像kissy，qwrap等大而全的框架(库)不多会有人去将其用到本身的产品中，通常是去学习它们的实现理念。而对于SeaJS等只实现单一功能，而且文件小，不依赖其它第三方库(框架)则大受欢迎，不少公司和我的都在本身的产品中使用。

 

    (4) jQuery

 

    jQuery是个特例，虽然通常只用到了它的DOM操做和ajax相关的API，这种状况下，要引入一个gzip压缩后30多K的文件，不算小了。可是jQuery太流行，它的写法已经成了前端开发事实上的规范，你们都会用它，并且不少第三方UI组件/框架/库都依赖它。

 

最后的总结

 

    上面提到的问题的性质需具体状况具体分析，根据应用产品的场景和开发团队要求，多是大问题，也可能不是问题。若是有一个稳定的前端团队，而且开发的产品打算长期优化，那么积累并完善本身的框架(库)就很是有必要了。当团队没有积累，而又有产品开发的进度限制时，能够根据产品的形态和场景，先选择成熟的第三方库（不必定是当前很是流行的），在长期的产品的优化和完善过程当中会不断发现问题并解决问题，这个过程能够逐步来构建和完善本身的框架（库）。