最近寫了一系列的關於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這樣的外掛吧
最後
這只是今天早上拍拍腦袋的初步計劃與設想，有很多缺陷，希望各位多給意見，如果不吝分享自己的就更感激不盡了。