在这个js框架随处乱跑的时代，你是否考虑过写一个自己的框架？下面的内容也许会有点帮助。
一个框架应该包含哪些内容？
1. 语言扩展
大部分现有的框架都提供了这部分内容，语言扩展应当是以ECMAScript为基础进行的，不应当依赖任何宿主环境，也就是说，作为一个框架的设计者，你应当保证你的语言扩展可以工作在任何宿主环境中，而不是仅仅适合浏览器环境。你必须保证把它放到WScript,SpiderMonkey Shell,Rhino Shell,Adobe ExtendScript Toolkit甚至Flash ActionScript等环境中都能正确的工作，举个现实一点的例子setTimeout不可以出现在其中，你也不能用XMLHTTP加载脚本运行，尽管它们看起来很贴近语言。保持这一部分的独立性可以让你方便的移植你的框架到其他宿主环境下。孟津县二中
2. 数据结构和算法
JS本身提供的内置对象非常有限，很多时候，框架应该提供一些数据结构和算法来帮助使用者更好的完成逻辑表达。但我认为随便翻本数据结构或者算法书用JS挑几个实现了加到框架中是不负责任的，多数数据结构应当以库的形式存在而非框架。框架中的数据结构应该足够常用而且实现不是非常复杂的，可以考虑的如集合、哈希表、链表、有序数组以及有序数组上的二分搜索。对JS来说，对象是一个天然的字符串哈希表，而集合很容易在哈希表上实现，因此只需要处理掉Object的内置方法，我们就可以实现一个高效的集合或哈希表。
3. DOM扩展
JS主要应用于Web开发，目前所有的框架也都用于浏览器环境，那么，浏览器端环境里重点中的重点DOM当然也是框架的扩展目标了，如果一个框架不提供DOM的扩展，那么其实基本没什么用处了。需要注意的是，DOM扩展也有w3c的标准可依，所以，不要尝试为各种浏览器做一些奇怪的扩展，比如FF下面的element们的prototype，框架的编写者应当无视它们。DOM扩展的主要任务之一是兼容性，不同浏览器上的DOM实现相差很多，框架必须消除这些实现带来的差异，提供统一的访问方式。当然，做为框架，应当提供一些更为方便的接口，将宿主提供的DOM对象用js对象封装是个不错的想法，但是同时这也很可能会造成内存泄露，所以做这事之前，了解内存泄露是必要的。实际上，自己想象的扩展远不如W3C的设计，比如如果你能更完整地实现XPath，你就能比JQuery做的更好。
4. AJAX扩展
大部分现有框架出现的原因都是因为AJAX，所以如果你想设计一个受欢迎的框架，AJAX是必须要做的。跟DOM扩展很相似，AJAX扩展的主要任务是兼容和内存泄露，对AJAX的核心组件XMLHttpRequest对象，必须在IE6中使用ActiveX创建，而ActiveX又有各种版本，而随之而来的内存泄露和兼容性变得非常麻烦，比如：事件函数名大小写、this指向、事件函数的null赋值。处理好这些兼容性的基础上，可以做进一步的工作，提供一些常用的实现。应该指出的是，除非你确定你提供的接口比原来的更好，否则不要改变原来的XMLHttpRequest对象的接口，比如写一个Request函数来代替open和send，如果你不清楚W3C的专家们为什么这么设计，请不要把他们想象成傻瓜。我想自己另外写一个兼容且内存安全的XMLHttpRequest加入到自己框架的命名空间里，使它从外部看上去跟W3C描述的XMLHttpRequest一模一样是不错的办法，对XMLHttpRequest我认为唯一可以考虑的修改是提供onsuccess事件。当然针对一些复杂功能的AJAX扩展也是可行的，比如HTMLHttpRequest类似的扩展可以让AJAX初学者喜欢你的框架。
5. 效果
时间效果是最能刺激用户神经的，渐隐、缓动、滑动、颜色渐变这些都很不错，其实技术难度也不是很高。拖动效果则是浏览器中一个很重要的效果，用鼠标事件来模拟本来很容易，不过兼容和setCapture也是很麻烦的事情。这一部分内容量力而为就可以了。
6. 脚本管理
因为大家非常喜欢C++风格的include或者JAVA风格的import，很多框架提供了基于AJAX的脚本管理，不过同步加载的效率问题是巨大的。之前我们曾经作过各种尝试，希望找到一个浏览器中不用XMLHTTP加载外部js的方法，但是最后得出的结论是：不可能 关于这个，略微思考就可以知道，Java C++ C#都是编译型语言，include 和import都是编译期处理，在js中做到类似的事情是不太可能的。为了实现类似的功能，我想我们可以利用服务端程序或者编写一个文本工具来实现。YUI将所有的js文件依赖关系提取出来的做法是可行的，不过这不能算是include的实现方式了，维护依赖关系不是一件很简单的事情。
7. 控件
EXT的成功告诉我们：提供优质的控件才是框架的王道。你不能指望优质的扩展会吸引更多使用者。多数人只关心如何快速完成手边的工作。当然不是所有框架都要提供这部分内容。控件好坏取决于能力和美工，不过至少要保证框架里的控件不会内存泄露。
框架设计的若干原则
1. 不要做多余的事
对这框架设计来说，我认为一个非常必要的原则就是不要做多余的事情，举个极端的的例子：
view source
print?
1 |
function add(a,b) |
2 |
{ |
3 |
return a+b; |
4 |
} |
这样的代码如果出现在框架中，就是个十足的笑话。不过大多数时候，事情不是那么明显，很多框架试图用某种形式在JS中"实现"OOP，但是实际上，JS本身是OO的（ECMA262中明确指出来的，不像某些人所说是基于对象云云）只是有一些语法跟Java等语言不同。那么显然这些OOP的"实现"其实是跟上面的例子一样的道理。另一个例子是Array.prototype.clone：
view source
print?
1 |
Array.prototype.clone=function(){ |
2 |
return this.slice(); |
3 |
} |
2. 慎用prototype扩展
很多框架利用修改原生对象的prototype来做语言扩展，但我认为应当小心地看待这件事，毫无疑问这将造成一定的命名污染，你无法保证框架的使用者或者与你的框架共存的其他框架不会使用同样的名字来完成其他的事情。特别需要注意的是，Object和Array这两个对象的prototype扩展格外的危险，对Object来说，如果Object被修改，那么框架的使用者将无法创建一个未被修改的干净的对象，这是一个致命的问题，尤其如果你的使用者喜欢用for in来反射一个对象的属性。Array.prototype修改的危险来自js一个不知有意还是无意的小小设计，对原生的Array来说，任何情况下for和for in的遍历结果是相同的，而因为无法控制自定义的属性是不可枚举的，任何Array.prototype的修改都会破坏这种特性。一方面，我认为不应当推荐用for in遍历数组，这其中包含着错误的语义。另一方面，框架的设计者必须尊重这些使用者，因为对于ECMA所定义的语法而言，它是正确的做法。其中包含着这样一个简单的事实：假如你的框架中修改了Array.prototype，那么一些之前能正确工作的代码变得不可正确工作。直接修改prototype看上去非常诱人，但是在考虑它之前应当先考虑两种可能的方案：
函数：提供一个以对象为第一个参数的函数比如 Array.prototype.each =>
view source
print?
1 |
function ForEach(arr,f) |
2 |
{ |
3 |
if(arr instanceof Array)/*...*/; |
4 |
} |
继承：以return的形式继承一个内置对象 比如考虑Array.prototype.each=>
view source
print?
1 |
function ArrayCollection() |
2 |
{ |
3 |
var r=Array.apply(this,arguments); |
4 |
r.each=function(){/*......*/}; |
5 |
return r; |
6 |
} |
套用一句名言，不要修改原生对象的prototype，除非你认为必要。不过修改原生对象的prototype确实有一些特殊的用途（就是"必要的情况"），主要体现在2点：文字量支持和链式表达。举一个例子可以体现这两点：
view source
print?
1 |
var cf=function f(a,b,c,d) |
2 |
{ |
3 |
/*........*/ |
4 |
}.$curry(3,4).$curry(5).$run(); |
如果希望实现类似上面的表达方式，可能就需要扩展Function.prototype，权衡一下的话，如果你认为命名污染的代价是值得的，那么也是可以提供给使用者的。
一个比较讨巧的办法是把选择权利交给使用者，提供一个扩展器：
view source
print?
1 |
function FunctionExtend() |
2 |
{ |
3 |
this.$curry=function(){/*......*/}; |
4 |
this.$run=function(){/*......*/}; |
5 |
} |
如果用户喜欢可以FunctionExtend.apply(Function.prototype); 如果不喜欢扩展 则可以
view source
print?
1 |
var r=function(){/*......*/}; |
2 |
FunctionExtend.apply(r); |
3. 保持和原生对象的一致
不知你有没有注意到，内置对象Function Array等都有这样的性质：new Function()跟Function的结果完全一致（String Number Boolean这种封装型对象没有这样的性质）
如果框架中提供的类也具有这种性质，会是不错的选择。这仅仅是一个例子，如果你注意到了其他细节，并且让框架中的类和原生对象保持一致，对使用者来说是非常有益的。
4. 尊重语言 尊重用户
编写框架应该尊重依赖的语言环境，在对原有的元素修改之前，首先应该考虑到原来的合理性，任何语言的原生环境提供的都是经过了精心设计的，在任何修改之前，至少应该考虑这几点：效率、命名规范、必要性、与其他功能是否重复。如果你没有付出至少跟语言的设计者相当的工作量，你的做法就是欠考虑的。
编写框架也应该尊重用户的所有习惯，将编写者的喜好强加给使用者并不是框架应该做的事情。框架应该保证大部分在没有框架环境下能运行的代码都能在框架下正常工作，这样用户不必为了使用你的框架而修改原有的代码。
5. 规范命名和使用命名空间
减少命名污染可以让你的框架跟其他框架更好地共存。很多框架使用了命名空间来管理，这是良好的设计。命名应该是清晰且有实际意义的英文单词，如前面3所述，为了保持和原生对象的一致，命名规则最好贴近原生对象，比如类名第一字母大写，方法名用驼峰命名。捎带一提prototype中的$实在是非常糟糕的设计，无法想象$出现的目的仅仅是为了让使用者少写几个字母。这种事情应该交给你的用户在局部代码中使用。