Thinking for Fun » JavaScript

Even Faster Web Sites: 读书笔记(二)

yongbin — Sun, 24 Jan 2010 08:54:18 +0000

这次因为一个项目的原因，又重读了《Even Faster Web Sites》书里的第四章：Loading scripts without blocking，并且在Cuzillion里做了大量测试，又发现了很多有意思的细节。发现自己读书太糙，自责一下。结合实际工作，加上自己的理解，再把这一章的实用内容总结一下。

要解决的问题

页面的script标签引入外部js文件时，会阻塞后续外部资源的下载和加载，包括图片、CSS文件、iframe等等。

1. Script DOM Element比较常用

“Script DOM Element”方法是常见的方法，也就是createElement(“script”)的方法下载js文件，以此并行加载后续资源。这其实是很棒的一个方法，因为不需要担心跨域，而且我们在中文应用中，不用担心编码的问题（可以为

假如行内js前有一个外部css文件（如上述代码），那么这段js要等到css文件完全下载完才会被执行，js被阻塞，造成了页面剩余内容被阻塞，恶劣的连锁反应被引发。

先总结这么多，欢迎指正！

获得原始href属性的方法

yongbin — Sat, 08 Aug 2009 05:35:16 +0000

JavaScript里得到某个链接的href属性时，有三种方式，总结一下：

1. 直接获得href属性，也就是

var url = el.href;  // el是一个a元素

2. 使用getAttribute方法，像这样：

var url = el.getAttribute("href");

3. IE下的getAttribute方法有第二个参数，参见msdn的这篇。第二个参数如果是2，意思是以字符串形式返回。

var url = el.getAttribute("href", 2);

获得href属性的这三种方法，同样的，有三点，让人很费解，而且浏览器实现各不相同。

如果href写的是相对地址，得到属性时，浏览器可能会自动转为绝对地址。（很多情况下我们是不希望这样的）
如果href里有汉字，浏览器会自动编码吗？
如果href里有特殊字符，浏览器会自动编码吗？例如大括号{}。

为此我做了一个小测试页面（点这里可测试），得到了如下的结果：

获得href和src属性的浏览器差异（相对地址与自动编码情况）
	.href	getAttribute(“href”)	getAttribute(“href”, 2)
IE6	转绝对，不编码	转绝对，不编码	正常
IE7	转绝对，汉字不编码，特殊符号编码	转绝对，汉字不编码，特殊符号编码	正常
IE8 as IE7	转绝对，汉字不编码，特殊符号编码	转绝对，汉字不编码，特殊符号编码	正常
IE8 standard	转绝对，汉字不编码，特殊符号编码	正常	正常
Firefox 3.0+	转绝对，全部编码	正常	正常
Chrome 2.0	转绝对，全部编码	正常	正常
Safari 4.0	转绝对，汉字编码，特殊符号不编码	正常	正常
Opera 10.0beta	转绝对，汉字编码，特殊符号不编码	正常	正常

其中，“正常”的意思是，得到href属性里原始链接，不自动转绝对地址、汉字和符号都不编码。

结论，如果想得到href里的未经转换、未经编码的原始内容，IE浏览器下全部使用getAttribute(“href”, 2)，其他浏览器下使用getAttribute(“href”)即可，这在序列化DOM时会非常有用；如果想得到绝对地址、编不编码没关系，那就用href属性。

JavaScript调试技巧之：断点调试(2)

yongbin — Tue, 04 Aug 2009 06:31:47 +0000

上次总结了Firefox下进行JavaScript断点调试的技巧，这次来看一下其他浏览器下的调试。一点说明，这里的调试技巧都不借助于浏览器之外的工具，例如Aptana，VS2008等。如果要找这方面的一些资料，我这里没有哈。

其他浏览器，主要是Opera, Safari, Chrome和IE8。这之中除了IE8，它们的调试功能都挺不错的，基本都可以搜索脚本，加入断点，查看调用栈、本地变量，以及强大的console。

1. 使用Opera的Dragonfly进行断点调试

使用Opera Dragonfly进行断点调试

打开Tools – Advanced – Developer Tools，即可看到类似于Firebug的开发工具，名字叫做Dragonfly，也就是蜻蜓。在这里可以查看页面结构，查看网络交互，以及断点调试，并且可以在调试过程中使用Command Line (console)。

Opera on WindowsXP也属于YUI要支持的A-grade（详见此表格），所以我们在开发的时候，也要尽量去支持。此外Dragonfly的DOM查看工具有一个亮点，Export current DOM view。我们可以在线做一些DOM改动，然后Export一下，即可得到改动后的HTML代码，非常方便。

2. 使用Chrome和Safari进行断点调试

如果你觉得Opera太小众，那么你可以在Safari或者Chrome上进行调试。两个浏览器的调试方式、界面极其相似，所以这里以Safari 4.0为例。打开Menu – Develop – Start Debugging JavaScript，即可弹出一个调试工具。值得一提的是，Safari和Chrome的调试工具最好不要Dock到浏览器下面，因为弹出来的话，调试界面是刚刚好的。

首先找到要调试的脚本：

使用Safari进行JavaScript调试：找到脚本

设置断点，重新加载页面（或者执行动作）：

使用Safari进行JavaScript调试：设置断点

在右侧查看本地变量和函数调用栈：

使用Safari进行JavaScript调试：变量查看

Safari的调试工具一个亮点是，console和断点调试在同一个界面上，这样可以非常方便地在程序中断时，利用console来做一些验证操作。

3. IE8的断点调试功能

IE8自带的开发者工具，虽然极其难用，但也可以断点调试。断点调试的方法与上述雷同。

使用IE8开发者工具进行断点调试

可以看到，IE8似乎莫名其妙地终止了js代码的识别。这样的话，从74行往后，都没办法加断点了，真不可思议。但我们有时为了兼容IE，不得不在IE下进行一些调试，怎么办呢？可以用上一篇文章的办法，在需要中断的位置加入debugger语句，这样程序运行时，IE8就会中断在debugger语句上了。

总结

有时候我们为了实现JavaScript程序的cross-browser，即兼容若干浏览器版本，会希望在不同浏览器上进行调试。IE8开发者工具出现之后，几大浏览器都可以调试了。先不论好不好用，总算都有了！

我的个人习惯是：对于一般的功能性调试，使用Firebug即可满足需求。Firefox扩展开发需要调试的，使用JavaScript Debugger（Venkman），页面脚本一般不用这个，因为它启动比较慢。对于浏览器兼容性需要的调试，使用该浏览器的开发者工具即可。对于IE6的调试……%￥……%……&×&×#￥%￥@@，我是没别的办法，只能用眼睛来调了……

欢迎交流！

JavaScript调试技巧之：断点调试(1)

yongbin — Mon, 03 Aug 2009 16:26:00 +0000

如果您还没有阅读《JavaScript调试技巧之：快速定位》，建议先看看那篇。说不定，用快速定位就能解决问题了，呵呵。这次我会总结记录一下断点调试的笔记，希望也对大家有用，欢迎补充交流！

首先，在各个浏览器中，断点调试支持的最好的当然是Firefox，Firefox不仅可以使用Firebug调试页面js脚本，还可以用高级调试工具例如JavaScript Debugger (Venkman) 来调试Firefox扩展里的js。除此之外，Firefox还支持一些更为高级的断点调试、变量监视功能。

其他浏览器里，Opera、Chrome和Safari的调试功能也比较好用。Opera的DragonFly速度相对比较快，界面清爽，功能强大，但不如Safari等友好。相比来说，IE8的程序员工具简直没法用。

这次时间有限，先来总结一下Firefox下的调试技巧。

1. 使用Firebug进行断点调试

使用Firebug调试JavaScript非常方便。具体步骤：

a. 打开Firebug后，启用“脚本”调试，找到引用的脚本文件（或者行内js）；

用Firebug找到要调试的脚本（点击放大）

b. 在适当的位置加入断点；

c. 如果断点已经执行过，则刷新页面，这时脚本就会在断点处中断。如果断点没有执行过，那可以直接执行页面上的动作（例如点击按钮等），然后代码会在断点处中断；

用Firebug进行断点调试（点击放大）

d. 观察函数调用栈，观察local变量，也可以进行单步执行，进行调试。

确实非常简单！用Firebug断点调试的优点总结如下：

能加断点的行用绿色行号，非常直观；
call stack用两种方式显示出来，很方便；
本地变量的显示非常清晰明了。

2. 使用JavaScript Debugger进行断点调试

这是老牌的调试工具，之前叫做Venkman，可以以扩展形式安装在Firefox上，我们在这里就称他为Venkman吧。它不仅能够调试页面脚本，还能调试Firefox扩展（extension）里的js。我们在做Firefox扩展开发时，Venkman是必不可少的工具，老田强力推荐！当然，Firefox本身的逻辑实现，也是用JavaScript来做到的。我们现在可以用Venkman来调试一下Firefox本身。Firefox的核心js是browser.js，在这个路径下：

chrome://browser/content/browser.js

我们打开Venkman之后，在Loaded Scripts里填入browser.js，这个js文件就会被过滤出来（如果没有看到browser.js，那么你可能需要查一下是否选上了Debug->Exclude browser files）。

Venkman：选择要调试的js文件（点击放大）

我们找到让浏览器后退的代码，然后点击Firefox的后退按钮，这时Venkman就会停在BrowserBack方法上！让我们再一步一步地看一看，Firefox自己到底做了什么。btw，实现Firefox的js代码也不是很漂亮嘛~~~

用JavaScript Debugger断点调试Firefox（点击放大）

Venkman当然也带有一个console，利用这个console，我们可以看一看浏览器层次的window和document都是什么东西。类似于Firebug和其他浏览器的console，只要直接输入js代码片段即可！

使用Venkman自带的console（点击放大）

有兴趣的话，可以在这里发现更多有关Firefox开发（以及扩展开发）的好玩的东西！

3. 使用debugger在程序中加入断点

另外还有一个少为人知的断点加入方法。我们可以在程序中加入debugger语句，这样Firefox的调试工具会停留在这条语句上，代码也暂停执行，和加入断点的效果一样。例如：

var myfunc = {
    get_field_value_callback : function() {
        debugger;
        var ed = this, target = ed.currSpan;
        /* do something more */
    }
}

这时重新加载页面，断点就会停留在debugger语句上。这样，我们就可以在写代码时随心所欲地加入断点了。另外，其他浏览器（包括IE8！Surprise！）同样支持debugger语句！

JavaScript调试技巧之：快速定位

yongbin — Thu, 23 Jul 2009 16:48:03 +0000

赶紧总结一下JavaScript的调试技巧，这次首先是“快速定位”篇。

快速定位，其实就是快速定位程序的错误，所以也算是调试。这个在实际的码代码时往往比较实用。大多数情况下，你的js代码不多（少于1000行），只要能迅速发现代码的错误，往往不用复杂的调试。关于常用的快速定位方法，我总结了一下几点，欢迎大家补充。

1. 使用alert

alert其实比较实用。本地调试中，在合适的位置写alert，打出来一些变量，虽然比较土，但是往往事半功倍！另外有一个alert技巧，想看看一个对象中的属性和它的值吗，试试这个：

var str = "", i;
for (i in obj) {
  str += i + ": " +obj[i] + "\n";
}
alert(str);

2. 使用地址栏

使用地址栏，输入javascript: doSomething()，可以在Runtime时输出或者执行一些代码。输出东西时也使用alert，例如在地址栏输入：

javascript: alert(document.getElementsByTagName("a").length);

可以输入当前的document下的链接数量。如果想执行已经加载的自定义函数，可以输入例如：

javascript: deleteFirstChildNode();

3. 错误查看器

最快捷的错误查看器当属Firefox的错误控制台，快捷键ctrl+shift+j。在你觉得脚本执行不正常时，首先按一下这个快捷键，往往能立刻知道哪里出了问题，并且点一下就能到问题脚本所在的位置，非常方便，强烈推荐！

4. 用浏览器的扩展或插件查看错误

这个话题比较大，一时说不完，所以先说说用扩展或插件来查看错误。对我来讲，Firebug一般就够用了，比较常见，就不截图了。启用Firebug控制台后，如果页面上js脚本错误，就会立刻在右下角显示出来，点击可以查看错误。有一点需注意，我的Firebug有时会报这个带乱码的错误：

 (¹Õ Location.toString

我一直不清楚这个为什么会乱码，但我知道这个是跨域的错误，比较常见。

其他浏览器的错误查看器，在这里我也简单总结一下：

Chrome：菜单 – 开发人员 – JavaScript控制台，下方可以看到类似于Firebug的console，在这里可以看到错误和警告信息。

Opera：菜单 – 工具 – 高级 – Error Console，功能比较强大，可以查看各类错误。

Safari：4.0版跟Chrome查看方式一样。Chrome/Opera/Safari都可以在Develope Tools里看到错误信息。

IE8：非常不好用，但是也有。开发人员工具 – Script标签 – 点击右边的console。在这个console里可以看到错误信息，但是不太友好。

5. console.log

在代码中使用console.log，也就是类似于alert，只不过把想要的信息输出到console里。console对象在Firefox、Chrome、Safari里都可以使用。除了console.log，还有console.error，console.info等等。详见Firebug的console API。

6. Console

最后正式介绍一下Console，也就是控制台。Life is short, use console！以Firebug的console为例，把几个常用功能介绍总结一下：

查看js对象

输入一个名字，例如window，window对象就会出现在结果中。这时可以点击这个window对象！点击以后就可以在DOM标签中查看这个对象的所有属性。那么现在应该能看到window下的全局变量了，方便吧！

查看DOM对象

输入document.getElementById(“el_id”)，这时el_id这个元素就会出现在结果中，点击可以看到它的详情，例如看看它当时的HTML代码。

在Runtime执行脚本

输入任何的js代码，立刻执行。这样可以很方便地测试页面上的脚本了。也可以在多行模式中执行输入的js。

关于这个console，在输入js脚本时，别忘了按tab键进行代码自动补齐哦！代码补齐和提示功能，在Chrome、Safari和Opera里同样有效，IE8就惨点了。Chrome和Safari做的也非常好，大家可以试一下啊。

简而言之，掌握快速定位，可以迅速解决JavaScript开发中的琐碎问题，以上办法中，我的建议是，遇到问题先用错误查看器看一下，不行再使用Console，基本上就能很快定位问题原因了！

提高JavaScript程序的鲁棒性

yongbin — Thu, 09 Jul 2009 18:17:08 +0000

我是学控制理论出身，一个控制系统的鲁棒性，确实是在做系统设计时需要着重注意的。什么是控制系统的鲁棒性？

所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性（摘自百度百科……汗）。

在软件设计和开发中，同样也要时刻考虑提高鲁棒性。那么如何提高JavaScript程序的鲁棒性呢？我认为，RIA的鲁棒性，一般来讲，主要跟js的代码规范性和DOM操作有关系。下面我总结几点开发中需要注意的地方，让页面跑不死、不报错。这些事情可能在实际开发中都是小事，但是对于提高软件整体的鲁棒性，是非常critical的！

1. 严禁使用全局变量

唉，这个我可是亲身体会并深受其害啊！话说，当时我修改一个页面，开发一段脚本，需要写cookie。我发现页面上以前有人引用了一个js文件，里面有setCookie函数，好啊，拿来用！结果这个cookie死活都写不对。检查了半天，才发现这个页面引用的另外一个js文件也有一个setCookie函数，函数的参数和刚才那个不一样，而我调用的估计是这个函数！应该是之前的两个同事在同一个页面上自己搞自己的，结果竟然函数重名，而这两个函数都是全局的！设想一下，加入两个人都在全局范围内搞一个var i = 0; 那岂不是更加疯掉。

这个故事得到的教训，首先当然是同一个team的开发者应该多兼容并包，团结协作。其次呢，页面的js较多的时候，一定要有一个好的层次，避免全局变量。避免全局变量的一个方式是namespace。例如创建一个这样的程序结构：

var my_project = {
  dom : {
    get : function() {},
    make : function() {} // etc.
  },
  cookie : {
    get : function() {},
    set : function() {},
    remove : function() {}
  },

  util : {
    // some project utilities
  }
}

2. 多使用短路表达式

全局变量的部分说的有点多了，大概是因为老田我经历过那类痛苦吧。短路表达式就是&&和||，在这里用来提高鲁棒性。举两个例子，第一，要得到某div节点的第一个节点的nodeName：

var div = document.getElementById("div_id");
var node_name;
if (div && div.firstChild) { // 在用firstChild前，先判断div是否存在
  node_name = div.firstChild.nodeName;
}

其次，用||来快速解决一些浏览器兼容性问题：

// 得到元素内文本的跨浏览器解决方案
var text = span.innerText || span.textContent || "";

再例，用||来设置默认值：

// 设置默认值
var my_attr = span.getAttribute("my_attr") || default_value;

3. 操作元素前，首先判断其存在

在第二条里面已经举过例子。再举一例：

var input = document.getElementsByName("input")[0];
if (input) {
  target = input.value;
}

4. 良好的代码缩进和格式

Doug Crockford，《JavaScirpt: The Good Parts》的作者，在给Google做演讲的时候，详细分析了代码格式的重要性。比如：

return
{
  name : span.nodeName,
  value : span.innerHTML
}

写这种代码的人肯定是C出身。js里面，后果就是return nothing。js有语句的自动补全机制，return这一样，会自动在末尾加上分号，导致返回。如果不注意的话，程序出了问题，很难找到原因。所以一定要养成一个代码格式的好习惯，把左大括号和return啊，if啊，function()啊，写在一起。也就是：

return {
  // something
}

5. 使用跨浏览器的代码

在对DOM进行读取和操作时，处处想着浏览器兼容性这件事，免得最后返工，自己给自己找麻烦。比如，只用document.getElementById；用nodeName，而不用tagName；不用getElementsByClassName等先进的选择器；不用applyElement, removeNode, swapNode等IE only的方法。

在浏览器兼容性方面，强烈推荐ppk的站点quirksmode.org。ppk此人对各个浏览器都进行了测试，工作十分扎实，是我们的榜样啊！

6. 变量尽早定义

JavaScript的变量作用域是所在的整个function，在写代码的时候，如果变量在想用的时候再定义，很容易变得难于管理。在开发逻辑比较复杂的程序时，非常容易混乱，甚至变量重名。

7. 小心NodeList

NodeList，也就是节点列表，是一个陷阱，他不是静态的，而是危险的动态结构，它会立即反映文档的变化。一个经典的死循环案例：

var lis = ul.getElementsByTagName("li");
for (var i = 0; i < lis.length; i++) {
  ul.appendChild(lis[i].cloneNode(true));
}

上面的代码里，这些li的length不是固定的，而是随着DOM的变化而变化。这个错误我是经历过一次啊，不过不是死循环。还拿这个ul和li举例子吧，我想删掉某个ul下面的所有li，代码类似于下面的样子，大家看看有什么问题呢？

var lis = ul.getElemenetsByTagName("li");
for (var i = 0; i < lis.length; i++) {
  ul.removeChild(lis[i]);
}

8. 使用===和!==

某些人可能会问，我用==用的挺好的啊，为什么要用===？那我要反问，既然===更加严谨，没有类型转换，而==充满陷阱，为什么不用===？没有自信吗？哦，那只能说明你的程序不稳定，鲁棒性不好了。

==会进行自动类型转换，Crockford称它为evil twins。其他的不说了，举几个例子：

alert(0 == '');  // true
alert(false == '0'); //true
alert('\r\n' == 0); // true

9. 不要用with

在设计JavaScript这门语言的时候，with本来是为一些操作提供快捷方式的，但是设计的不够好，可以说js里面没有with会更好。举一个使用with的例子：

with(element.style) {
  position = "absolute";
  left = "100px";
  top = "100px";
}

首先with破坏了这门语言的变量作用域结构。在js里面，postion, left和top本来应该变成全局变量的。可能有些人说，这样正好，我可以通过with来控制变量作用域！想法不错，JavaScript 1.7也引入了let语句来做这件事。但是，with会产生无法预想的后果，举例：

var a = '';
var obj = {b: 'b'};
with(obj) {
 a = b;
}
alert(a); // result: 'b'

这里的a又变成外部变量了！除了这种诡异的事情之外，with语句的执行速度相对来说是非常缓慢的。所以结论就是，想要提高程序的鲁棒性，就不要用with。

10. 不要用eval

eval可以把一段字符串当作js代码来执行。eval经常被一些新手拿来用，例如：

eval("value = obj." + key + ";");

其实他完全可以：

value = obj["key"];

eval执行的时候会启用js解释器来执行这一小片代码，速度会慢很多。除此之外，程序的可调试性、可维护性大大降低。类eval的语句还有：

window.setTimeout("var i = 0", 1000);

var sum = new Function("x", "y", "return x+y");

Web应用程序的beta精神

yongbin — Thu, 09 Jul 2009 14:59:38 +0000

Gmail的logo上终于没有了Beta字样，于此同时，Google Calendar，Google Docs也脱离了beta。Gmail长达七年之久的开发与测试终于结束。

Gmail最初设计稿的其中一张（图片来源：TechCrunch）

从2004年的愚人节到现在，Gmail一直beta着。在此期间，Gmail小组又加入了很多创新性、革命性的东西在里面。例如加入了Gtalk，让大家在网页上聊天，甚至后来在网页上视频通话；加入了pop邮件的功能；使用long polling来实时获取新邮件；创新性地用标签，而不是文件夹来分类邮件。这些都是之前的网页开发者很难想象、很难做到的。

不过，更值得一提的是web应用程序的beta精神。Web App和桌面程序不同，有很多因素会影响其稳定性。例如网络环境，例如浏览器的兼容性和浏览器设置等等。事实上JavaScript本身就是一个设计上存在缺陷的语言，浏览器对它的支持也不尽相同，而CSS在不同浏览器下的差异更是让我们费尽脑子。这些因素都让我们无法理直气壮地说自己的web程序没有问题。一个复杂的网页程序，在Firefox下运行正常了，你敢说在IE5.5下运行也正常？你敢说在Konqueror下显示和运行都没有问题？大概正因如此，Gmail一直都没有脱离beta。也就是说，上个世纪的浏览器大战造成的兼容性问题，折磨了Gmail整整7年啊。

关于对浏览器的支持，Yahoo!有他的GBS表，也就是Graded Browser Support，很被国外的开发者认可（btw前一段时间刚刚drop掉了IE6 on Windows2000，让我倍感欣慰，说明XP下也不远了！）。

YUI Graded Browser Support Chart

（图片来源，Yahoo! UI Library）

我认为可以用这个表格当作一个web程序可称为正式版的参考。不知道Google是不是也用的这个表格，或者有一个类似的chart。无论如何，Gmail beta 5年告诉我们，一个web应用程序，想要说自己是正式版，很难。

由IE一例处理comment节点的bug得到的结论

yongbin — Thu, 09 Jul 2009 12:05:18 +0000

近期处理一个项目，需要“翻译”页面的注释节点。功能在Firefox下一切正常，项目进行非常顺利。拿到IE全系列下，却非常不正常，把注释翻译成ELEMENT Node，页面立刻飞掉。检查不出来原因，抓狂了好几天。

后来发现，问题出在IE渲染li的时候。我们的项目里，有时候要求注释节点需要插入在li的后面。虽然这不太标准，但是实际应用中，也是没办法的事。IE6+会把注释节点包进li里面，真是无语。

例如页面上的代码：


  
  asdf
  asdf
  asdf

试试document.getElementById(“test”).innerHTML，弹出：


asdf
asdf
asdf

用IE8的开发者工具，也能看到同样的效果。IE其实是用这个代码来渲染页面的。最后的解决办法只好先“预处理”一下，把注释节点挪出来，大概是这样：

var lis = document.getElementsByTagName("li");
for (var i = 0, l = lis.length; i < l; i++) {
  if (lis[i].lastChild.nodeType === \8) {
    lis[i].parentNode.appendChild(lis[i].lastChild);
  }
}

这个bug说明一个问题，IE系列浏览器，包括IE8，内部的渲染还是使用的陈旧的HTML渲染方式，哪怕页面的文档类型DOCTYPE是xhtml。像这次遇到的问题，真是很难发现。IE浏览器真是无端耗费我们的青春啊！