为什么需要自己实现前端框架
1个回答
展开全部
前端对框架(库)的大小更敏感
前端内容的渲染和交互效果的实现如果依赖JS框架(库),需要先将这些框架(库)下载到客户端,此时框架(库)的大小将直接影响到前端的首屏渲染速度。框架(库)越小,加载的速度就越快,而随着功能的越来越全,框架(库)必然会越来越大,要保证性能,需要制定加载策略。
便于制定加载策略
解决框架(库)变大的常见加载策略是将框架分为核心部分和扩展部分,核心部分在首屏渲染前必须下载完成,并且这部分的加载文件尽可能的少和小,扩展部分则可以模块化方式来懒加载。
核心部分的JS在发布时,可对文件合并,数量尽可能少,单个文件在gzip压缩后最好不要超过20K。核心部分可以是实现“JS语言扩展(面向对象),DOM操作API,数据交互方法(ajax),导航策略,模块化底层实现,事件底层实现,模版解析”等。扩展部分一般是一些可异步加载的UI组件,例如:输入控件、弹出窗、动画API、文件上传及预览、图表控件、富文本编辑器等。
上面的实现模式,在主流的JS框架(库)中,有三类选择:一类是以ExtJS为代表的大而全的框架(库),这类框架虽然功能满足,但往往无法拆分为核心部分和扩展部分来加载,因此基本不予考虑;一类是相对轻量的YUI3、Dojo等框架(库);一类是近来流行的前端MV*系列Backbone、Ember、Angular,这类在充当核心部分时,还需要组合Underscore、RequireJS,jQuery等第三方库。
后面两类可以满足要求,但个人觉得不是完美的方案,因为在开发实际产品时,将这两类作为核心部分时,往往里面有很多是不需要的,而还有些需要自己来额外补充近来,可以是自己开发,也可以集成第三方的实现。而核心部分框架(库)如果是自己实现,则可以保证在功能完整的情况下,不多出其它的东西,加载的JS可以控制到最小,而且代码风格也统一。
便于扩展
前端代码与用户的交互直接相关,而交互的设计变化和不确定性非常大,现成的第三方实现往往难以直接利用,需要改造。有时改造第三方的框架,先要非常熟悉框架,当这个框架比较复杂时,这样的工作量和难度就大大加大了。而自实现的框架(库)则可以根据需要任意扩展,可以根据需求制定对应的规范和API。
前端内容的渲染和交互效果的实现如果依赖JS框架(库),需要先将这些框架(库)下载到客户端,此时框架(库)的大小将直接影响到前端的首屏渲染速度。框架(库)越小,加载的速度就越快,而随着功能的越来越全,框架(库)必然会越来越大,要保证性能,需要制定加载策略。
便于制定加载策略
解决框架(库)变大的常见加载策略是将框架分为核心部分和扩展部分,核心部分在首屏渲染前必须下载完成,并且这部分的加载文件尽可能的少和小,扩展部分则可以模块化方式来懒加载。
核心部分的JS在发布时,可对文件合并,数量尽可能少,单个文件在gzip压缩后最好不要超过20K。核心部分可以是实现“JS语言扩展(面向对象),DOM操作API,数据交互方法(ajax),导航策略,模块化底层实现,事件底层实现,模版解析”等。扩展部分一般是一些可异步加载的UI组件,例如:输入控件、弹出窗、动画API、文件上传及预览、图表控件、富文本编辑器等。
上面的实现模式,在主流的JS框架(库)中,有三类选择:一类是以ExtJS为代表的大而全的框架(库),这类框架虽然功能满足,但往往无法拆分为核心部分和扩展部分来加载,因此基本不予考虑;一类是相对轻量的YUI3、Dojo等框架(库);一类是近来流行的前端MV*系列Backbone、Ember、Angular,这类在充当核心部分时,还需要组合Underscore、RequireJS,jQuery等第三方库。
后面两类可以满足要求,但个人觉得不是完美的方案,因为在开发实际产品时,将这两类作为核心部分时,往往里面有很多是不需要的,而还有些需要自己来额外补充近来,可以是自己开发,也可以集成第三方的实现。而核心部分框架(库)如果是自己实现,则可以保证在功能完整的情况下,不多出其它的东西,加载的JS可以控制到最小,而且代码风格也统一。
便于扩展
前端代码与用户的交互直接相关,而交互的设计变化和不确定性非常大,现成的第三方实现往往难以直接利用,需要改造。有时改造第三方的框架,先要非常熟悉框架,当这个框架比较复杂时,这样的工作量和难度就大大加大了。而自实现的框架(库)则可以根据需要任意扩展,可以根据需求制定对应的规范和API。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询