事件委派
Web应用都是由事件驱动运转的。我喜欢事件处理，尤其喜欢自己定义事件。
它能使你的产品可扩展，而不用改动核心代码。
有一个很大的问题(也可以说是功能强大的表现)，是关于页面上事件的移除问题。你可以对某个元素安装一个事件监听器，事件监听器就开始运转工作。
但页面上没有任何指示说明这有个监听器。因为这种不可表现的问题 (这尤其让一些新手头疼) ，以及像IE6这样的”浏览器“在太多的使用事件监听时会出现各种的内存问题，你不得不承认尽量少使用事件编程是个明智的做法。
于是 事件委托 就出现了。
当页面上某个元素上的事件触发时，而在 DOM 继承关系上，这个元素的所有子元素也能接收到这个事件，这时你可以使用一个在父元素上的事件处理器来处理，而不是使用一堆的各个子元素上的事件监听器来处理。
究竟是什么意思?这样说吧，页面上有很多超链接，你不想直接使用这些链接，想通过一个函数来调用这个链接，
HTML代码是这样的：
2 <ul id="resources">
3 <li><a href="http://opera.com/wsc">Opera Web Standards
Curriculum</a></li>
4 <li><a href="http://sitepoint.com">Sitepoint</a></li>
5 <li><a href="http://alistapart.com">A List Apart</a></li>
6 <li><a href="http://yuiblog.com">YUI Blog</a></li>
7 <li><a href="http://blameitonthevoices.com">Blame it on the voices</a></li>
8 <li><a href="http://oddlyspecific.com">Oddly specific</a></li>
9 </ul>
常见的做法是通过循环这些链接，将每个链接上附加一个事件处理器：
02 (function(){
03 var resources
= document.getElementById('resources');
04 var links =
resources.getElementsByTagName('a');
05 var all =
links.length;
06 for(var i=0;i
07 // Attach a listener to each link
08 links[i].addEventListener('click',handler,false);
09 };
10 function handler(e){
11 var x =
e.target; // Get the link that was
clicked
12 alert(x);
13 e.preventDefault();
14 };
15 })();
我们用一个事件处理器也能完成这项任务：
02 var resources
= document.getElementById('resources');
03 resources.addEventListener('click',handler,false);
04 function handler(e){
05 var x =
e.target; // get the link tha
06 if(x.nodeName.toLowerCase()
=== 'a'){
07 alert('Event
delegation:' + x);
08 e.preventDefault();
09 }
10 };
11 })();
因为点击事件就发生在这些页面元素里，你要做的就是比较它们的 nodeName，找出应该回应这个事件的那个元素。
免责声明：上面说的这两个关于事件的例子，在所有浏览器里都能运行，除了IE6，在IE6上你需要使用一个事件模型，而不是简单的W3C的标准实现。这也就是我们推荐使用一些工具包的原因。
这种方法的好处并不是仅限于把多个事件处理器缩减为一个。你想想，举个例子，你需要动态的往这个链接表里追加更多的链接。使用事件委托后，你就不需要做其它修改了;否则的话，你需要重新循环这个链接表，重新给每个链接安装事件处理器。
匿名函数和模块化
在JavaScript里最令人懊恼的事情是变量没有使用范围。任何变量，函数，数组，对象，只要不在函数内部，都被认为是全局的，这就是说，这个页面上的其它脚本也可以访问它，而且可以覆盖重写它。
解决办法是，把你的变量放在一个匿名函数内部，定义完之后立即调用它。
例如，下面的写法将会产生三个全局变量和两个全局函数：
2 var age = '34';
3 var status = 'single';
4 function createMember(){
5 // [...]
6 }
7 function getMemberDetails(){
8 // [...]
9 }
如果这个页面上的其它脚本里也存在一个叫 status 的变量，麻烦就会出现。
如果我们把它们封装在一个 myApplication 里，
这个问题就迎刃而解了：
= function(){
02 var name = 'Chris';
03 var age = '34';
04 var status = 'single';
05 function createMember(){
06 // [...]
07 }
08 function getMemberDetails(){
09 // [...]
10 }
11 }();
但是，这样一来，在函数外面就没有什么功能了。如果这是你需要的，那就可以了。你还可以省去函数的名称：
02 var name = 'Chris';
03 var age = '34';
04 var status = 'single';
05 function createMember(){
06 // [...]
07 }
08 function getMemberDetails(){
09 // [...]
10 }
11 })();
如果你想在函数外面也能使用里面的东西，那就要做些修改。
为了能访问 createMember() 或 getMemberDetails(),
你需要把它们变成 myApplication的属性，从而把它们暴露于外部的世界:
= function(){
02 var name = 'Chris';
03 var age = '34';
04 var status = 'single';
05 return{
06 createMember:function(){
07 // [...]
08 },
09 getMemberDetails:function(){
10 // [...]
11 }
12 }
13 }();
14 //
myApplication.createMember() 和
15 //
myApplication.getMemberDetails() 就可以使用了。
这被称作 module 模式或 singleton。
Douglas Crockford 多次谈到过这些，Yahoo User Interface Library YUI 里对此有大量的使用。
但这样一来让我感到不便的是，我需要改变句式来使函数和变量能被外界访问。更甚者，调用时我还需要加上myApplication 这个前缀。所以，我不喜欢这样做，我更愿意简单的把需要能被外界访问的元素的指针导出来。这样做后，反倒简化了外界调用的写法：
= function(){
02 var name = 'Chris';
03 var age = '34';
04 var status = 'single';
05 function createMember(){
06 // [...]
07 }
08 function getMemberDetails(){
09 // [...]
10 }
11 return{
12 create:createMember,
13 get:getMemberDetails
14 }
15 }();
16 //现在写成 myApplication.get()
和 myApplication.create() 就行了。
我把这个称作 “revealing
module pattern.”
可配置化
一旦我把所写的JavaScript代码发布到这个世界上，就有人想改动它，通常是人们想让它完成一些它本身完成不了的任务—但通常也是我写的程序不够灵活，没有提供用户可自定义的功能。
解决办法是给你的脚本增加一个配置项对象。
我 曾经写过一篇深入介绍JavaScript配置项对象的文章，下面是其中的要点：
在你的脚本了添加一个叫做 configuration 的对象。
这个对象里面，存放所有人们在使用这个脚本时经常要改动的东西：
CSS ID 和类名称;
按钮的名称，标签字等;
诸如”每页显示图片数”的值， “图像的显示的尺寸”的值;
地点，位置，以及语言设置。
将这个对象作为一个公用属性返回给用户，这样用户可以修改覆盖它。
通常情况下这是你编程过程中的最后一步要做的事情。我把这些集中表现在了一个例子里： “Five
things to do to a script before handing it over to the next developer.”
实际上，你也希望你的代码能够让人们很方面的使用，并且根据他们各自的需要进行一些改动。
如果你实现了这个功能，你会少收到一些抱怨你的脚本的人发送给你的让你困惑的邮件，这些信件会告诉你，有人修改了你的脚本，而且很好用。
与后台交互
在这么多年的编程经历中，我所领悟到的一个重要的事情就是，JavaScript是一个很优秀的开发界面交互的语言，但如果用来处理数字或访问数据源，那就有点使不上劲了。
最初，我学习JavaScript，是用来替代Perl的，因为我很讨厌非要把代码拷贝到 cgi-bin 文件夹下才能使Perl运行。
后来，我明白了应该使用一种后台工作的语言来处理主要的数据，而不能什么事情都让JavaScript去做。更重要的是我们要考虑安全性和语言特征。
如果我访问一个Web service, 我可以获取到JSON-P 格式的数据，在客户端浏览器里我把它做各种各样的数据转换，
但当我有了服务器时，我有了更多的方法来转换数据，我可以在Server端生成JSON或HTML格式的数据返回给客户端，以及缓存数据等操作。
如果你事先了解了并准备了这些，你会长期收益，省去了很多头疼的时间。
编写适用各种浏览器的程序是种浪费时间，使用工具包吧!
在我最初开始搞Web开发时，在访问页面时，究竟是使用 document.all 还是使用 document.layers 的问题上痛苦的挣扎了很久。
我选择了 document.layers，因为我喜欢任何层都是自己的document的思想 (而且我写了太多的 document.write 来生成元素)。层模式最终失败了，于是我开始使用 document.all。
当Netscape 6 公布只支持 W3C DOM 模型时，我很高兴，但其实用户并不关心这些。用户只是看见这种浏览器不能显示大多数浏览器都能正常显示的东西—这是我们编码的问题。我们编写了短视的代码，只能运行在当前的环境下，而不幸的是，我们的运行环境却在不停的改变。我已经浪费了太多的时间来处理对各种浏览器各种版本兼容的问题。善于处理这类问题提供了我一个好的工作机会。但现在我们不必在忍受这种痛苦了。一些工具包，例如 YUI, jQuery 以及Dojo 都能够帮我们处理这类问题。
它们通过抽象各种接口实现来处理浏览器的各种问题，像版本不兼容，设计缺陷等，把我们从痛苦中解救出来。
除非你要测试某个Beta版的浏览器，千万不要在自己的程序里添加修正浏览器的缺陷的代码，因为你很有可能当浏览器已经修改了这个问题时，你却忘了删除你的代码。另一方面，完全依赖于工具包也是个短视的行为。工具包可以帮你快速的开发，但如果你不深入理解JavaScript，你也会做错事。
