最近寫了一系列的關於JavaScript文章，時不時就會蹦出個需求，需要寫個特定的小函數，或者是為了解決瀏覽器兼容性問題，或者是簡化一些操作，前面寫的幾篇博客實際上已經寫出了一些常用的函數，既然自己希望在兩年內變成個技術小牛，提前准備自己的庫函數吧。
框架選擇
是個庫函數都會有自己的框架，我常用的有兩種形式，一種可以歸結為靜態方法型，大概定義一個立即執行函數，對外提供一個對象引用，自己定義的庫函數都作為這個對象的靜態函數供外部使用訪問；類外一種就是一個類jQuery的集成解決方案，相信介紹我就不必多說了。
這兩種方式各有利弊吧，經過數次糾結還是決定使用靜態方法，好處有幾個
1. 代碼可讀性還稍微高那么一小點兒，因為相對於類jQuery這樣的寫法還是更好理解一些，方便別人讀代碼
2. 現在大部分網站包括我們公司自己的網站中大部分頁面已經引用了jQuery，在寫一個類似的實際意義不大，而寫一個靜態方法的可以在沒有應用jQuery的頁面上阻隔簡單的拓展
3. 從實用性上考慮，實際上要不是因為有些比較復雜的選擇器瀏覽器兼容性問題，我幾乎是不使用jQuery的，而平時自己寫一些demo頁面，結構很簡單，根本用不到復雜的選擇器，相反最常用的就是綁定方法等這些小功能，寫個靜態方法類的平時用起來更方便
選定了框架后看看標題，有些難為情，因為下面這兩句就是框架的代碼，這么簡單都不好意思稱之為框架
//JavaScript原生對象拓展文件
庫文件
(function (window) { var ssLib={
//內部函數
//1.Event //2.DOM 拓展、CSS //3.Ajax //4.動畫 //5.簡單插件 }; window.ssLib = ssLib; //對外提供接口 })(window);
組織結構及內容
在讀jQuery源碼的時候我發現很難讀，里面各種方法穿插，經常讀到某句的時候，發現其調用了一個內部函數，然后再去找這個內部函數在哪里，好麻煩，所以在自己寫的庫函數里面干脆把公用的內部函數寫到最前面，方便查找。
看過一些書講過jQuery的一個好處就是不會與未來的API沖突，如果對JavaScript原生對象進行拓展很大可能會與未來API沖突，除非把名字起的非常奇怪，這里就盡量做一下判斷原生的有沒有，並且隨時關注人家未來API是什么樣子，盡量把作用及返回結果保持一致，使IE低版本用起來也不會感覺很奇怪。
（后記：最近聽取朋友意見將JavaScript原生對象拓展部分抽取出庫函數，放到了一個extention.js內）
我平時除了選擇器用的最頻繁的大概就是Event處理了（最近在做插件），所以把它放到最前面，DOM拓展、CSS部分希望寫一些對class的處理、對DOM元素移動、添加、刪除等處理，Ajax及動畫就是那么回事兒了，簡單插件部分希望添加像Dialog、Tab、Tree這樣的插件吧
最后
這只是今天早上拍拍腦袋的初步計划與設想，有很多缺陷，希望各位多給意見，如果不吝分享自己的就更感激不盡了。