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

　　js模塊和文件的管理

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

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

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

　　主流的思路

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

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

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