据说每个大牛、小牛都应该有自己的库——框架篇

最近写了一系列的关于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这样的插件吧

最后

这只是今天早上拍拍脑袋的初步计划与设想，有很多缺陷，希望各位多给意见，如果不吝分享自己的就更感激不尽了。