zoukankan      html  css  js  c++  java
  • 为什么需要自己实现前端框架

    前端对框架(库)的大小更敏感
     
        前端内容的渲染和交互效果的实现如果依赖JS框架(库),需要先将这些框架(库)下载到客户端,此时框架(库)的大小将直接影响到前端的首屏渲染速度。框架(库)越小,加载的速度就越快,而随着功能的越来越全,框架(库)必然会越来越大,要保证性能,需要制定加载策略。
     
    便于制定加载策略
     
        解决框架(库)变大的常见加载策略是将框架分为核心部分和扩展部分,核心部分在首屏渲染前必须下载完成,并且这部分的加载文件尽可能的少和小,扩展部分则可以模块化方式来懒加载。
        
        核心部分的JS在发布时,可对文件合并,数量尽可能少,单个文件在gzip压缩后最好不要超过20K。核心部分可以是实现“JS语言扩展(面向对象),DOM操作API,数据交互方法(ajax),导航策略,模块化底层实现,事件底层实现,模版解析”等。扩展部分一般是一些可异步加载的UI组件,例如:输入控件、弹出窗、动画API、文件上传及预览、图表控件、富文本编辑器等。
     
        上面的实现模式,在主流的JS框架(库)中,有三类选择:一类是以ExtJS为代表的大而全的框架(库),这类框架虽然功能满足,但往往无法拆分为核心部分和扩展部分来加载,因此基本不予考虑;一类是相对轻量的YUI3、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组件/框架/库都依赖它。
     
    最后的总结
     
        上面提到的问题的性质需具体情况具体分析,根据应用产品的场景和开发团队要求,可能是大问题,也可能不是问题。如果有一个稳定的前端团队,并且开发的产品打算长期优化,那么积累并完善自己的框架(库)就非常有必要了。当团队没有积累,而又有产品开发的进度限制时,可以根据产品的形态和场景,先选择成熟的第三方库(不一定是当前非常流行的),在长期的产品的优化和完善过程中会不断发现问题并解决问题,这个过程可以逐步来构建和完善自己的框架(库)。
  • 相关阅读:
    从零开始——PowerShell应用入门(全例子入门讲解)
    详解C# Tuple VS ValueTuple(元组类 VS 值元组)
    How To Configure VMware fencing using fence_vmware_soap in RHEL High Availability Add On——RHEL Pacemaker中配置STONITH
    DB太大?一键帮你收缩所有DB文件大小(Shrink Files for All Databases in SQL Server)
    SQL Server on Red Hat Enterprise Linux——RHEL上的SQL Server(全截图)
    SQL Server on Ubuntu——Ubuntu上的SQL Server(全截图)
    微软SQL Server认证最新信息(17年5月22日更新),感兴趣的进来看看哟
    Configure Always On Availability Group for SQL Server on RHEL——Red Hat Enterprise Linux上配置SQL Server Always On Availability Group
    3分钟带你了解PowerShell发展历程——PowerShell各版本资料整理
    由Find All References引发的思考。,
  • 原文地址:https://www.cnblogs.com/littlehb/p/3867140.html
Copyright © 2011-2022 走看看