前端基础框架的思考和尝试


  本文标签:前端 基础 框架

  近日我一直在思考类似的关于js模块和文件管理的方式  。正好团队里也正有这样的需求,于是,经历了好几天的苦思冥想,稍微做了些尝试  。下面会细细道来  。

  【js模块和文件的管理】

  基于这个title,前提是我们已经明确了我们有了一个组件或者js methods 的lib,我们暂且把它叫做库,库里面存储了很多我们常用的东西,比如js插件,封装好的methods 
以及其他的一些lib组件  。为了更好的管理我们这些颗粒化的js文件,我们的库通常都是呈颗粒化的  。基于这种情况,我们可以说一个js文件就对应一个模块module,他有他相对独立的功能  。这种管理模式是目前大多数主流框架的文件和模块管理模式,如YUI,EXT等,这样的好处是,可以按需调用  。并且调用的模块一目了然  。但是这样也有一个弊端,就是如果一个页面需要多个模块的支持,那么自然就需要加载对应的多个模块的js文件,http连接数自然会增加  。这对网站的性能来说当然是不好的  。所以,YUI等成熟的框架自然不会遗漏这个问题,他们也有一套自己注册和管理模块的机制(可以参考YUI的register和loader模块)

  当然,jQuery凭借他易用的api风格和强大的选择器也赢得了很大的市场,但是我们通常喜欢把jQuery叫做一个方法库,而不是框架的原因是它相对于其他框架而言的话,对模块和文件的管理就稍逊一筹  。虽然他后来的新版本也提供了自己的模块管理机制...

  但是,这并不存在谁对谁错,谁好谁坏的问题,只是各自的侧重点不同而已  。建站者选择谁只是看谁更适合自己而已  。有些企业觉得YUI的架构模式更适合自己,于是选择了跟他相似的模式,于是有了百度的Tangram,淘宝的kissy,有的企业觉得jQuery更适合现在的自己,于是选择的jQuery,比如豆瓣,于是也有了克军的轻量级前端框架Do  。我相信每个团队能够出一套自己的框架或者库都是不容易的,都是需要时间积累的,所以我从不轻易地评论别人的成果  。

  【主流的思路】

  由于不是简单的把页面上加载的  

  第三个参数为所要显示载入信息的dom元素id  。结果会如下显示:

  

  4  。这样的方式对性能到底有没有好处?
--答案,有的,下面上普通的阻塞和非阻塞方式载入jQuery源码的对比图:
直接页面上载入js的方式
 

  1. "text/javascript" src="http://common.cnblogs.com/script/jquery.js?99">  
 

  最后一条长长的载入时间就是jq的载入时间,故用户看到完整页面的时间为整个文件全部载入完成后的时间,大概为500ms左右(这单单是一个空文档载入jquery文件的时间)  。 

  以非阻塞方式载入时: 

  1. "text/javascript">  
  2. JS.add(jqhttp://common.cnblogs.com/script/jquery.js?111);  
  3. JS.use(jqfunction () {  
  4.     alert($)  
  5. })  
  6.  

   

  为了保证每次载入不会从缓存中读取,我加了个版本号?111;可以发现,上面的蓝线为用户感知到的页面download时间,在20ms左右,而jq文件的加载在蓝线后面,所以说这部分时间是用户感知不到的  。对用户体验的提升应该是大有帮助的  。就是给服务器增加了并发连接数  。

  好的,文章大概到这里,可能有人会说,基本上同样的事情Do.js,using.js,require.js等小众型框架已经都有了 ,为什么要自己再写?恩...别人的东西始终是别人的,自己做过的东西才真正是自己的  。

  我当然不敢说比别的大牛们考虑的更周到,效率更高,但是希望能在自己的编码中得到一点提高吧  。