近日我一直在思考類似的關(guān)于js模塊和文件管理的方式。正好團(tuán)隊(duì)里也正有這樣的需求，于是，經(jīng)歷了好幾天的苦思冥想，稍微做了些嘗試。下面會細(xì)細(xì)道來。

　　js模塊和文件的管理

　　基于這個(gè)title，前提是我們已經(jīng)明確了我們有了一個(gè)組件或者js methods 的lib，我們暫且把它叫做庫，庫里面存儲了很多我們常用的東西，比如js插件，封裝好的methods 
　　以及其他的一些lib組件。為了更好的管理我們這些顆粒化的js文件，我們的庫通常都是呈顆粒化的。基于這種情況，我們可以說一個(gè)js文件就對應(yīng)一個(gè)模塊module，他有他相對獨(dú)立的功能。這種管理模式是目前大多數(shù)主流框架的文件和模塊管理模式，如YUI，EXT等，這樣的好處是，可以按需調(diào)用。并且調(diào)用的模塊一目了然。但是這樣也有一個(gè)弊端，就是如果一個(gè)頁面需要多個(gè)模塊的支持，那么自然就需要加載對應(yīng)的多個(gè)模塊的js文件，http連接數(shù)自然會增加。這對網(wǎng)站的性能來說當(dāng)然是不好的。所以，YUI等成熟的框架自然不會遺漏這個(gè)問題，他們也有一套自己注冊和管理模塊的機(jī)制（可以參考YUI的register和loader模塊）

　　當(dāng)然，jQuery憑借他易用的api風(fēng)格和強(qiáng)大的選擇器也贏得了很大的市場，但是我們通常喜歡把jQuery叫做一個(gè)方法庫，而不是框架的原因是它相對于其他框架而言的話，對模塊和文件的管理就稍遜一籌。雖然他后來的新版本也提供了自己的模塊管理機(jī)制...

　　但是，這并不存在誰對誰錯(cuò)，誰好誰壞的問題，只是各自的側(cè)重點(diǎn)不同而已。建站者選擇誰只是看誰更適合自己而已。有些企業(yè)覺得YUI的架構(gòu)模式更適合自己，于是選擇了跟他相似的模式，于是有了百度的Tangram，淘寶的kissy，有的企業(yè)覺得jQuery更適合現(xiàn)在的自己，于是選擇的jQuery，比如豆瓣，于是也有了克軍的輕量級前端框架Do。我相信每個(gè)團(tuán)隊(duì)能夠出一套自己的框架或者庫都是不容易的，都是需要時(shí)間積累的，所以我從不輕易地評論別人的成果。

　　主流的思路

　　由于不是簡單的把頁面上加載的<script>轉(zhuǎn)變成動態(tài)scriptNode添加，所以需要考慮的問題其實(shí)并不少。
　　比如我們要加載一個(gè)新模塊a，對應(yīng)的顆粒化文件為a.js，那么我們大概可以表示為

it知識庫：前端基礎(chǔ)框架的思考和嘗試，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。