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

　　js模塊和文件的管理

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

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

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

　　主流的思路

　　由于不是簡單的把頁面上加載的<script>轉變成動態scriptNode添加，所以需要考慮的問題其實并不少。
　　比如我們要加載一個新模塊a，對應的顆?；募閍.js，那么我們大概可以表示為

it知識庫：前端基礎框架的思考和嘗試，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。