五种常见 Ajax 反模式

Jack Herrington 根据自己在 Ajax 领域的开发经验，撰写了一篇文章，深入讨论了 Ajax 代码中常犯的错误。他阐述了五个足以被认定为反模式（anti-pattern）的常见具体问题，总结如下：

滥用定时器（Timer）进行轮流监测。尽管 JavaScript 拥有定时器功能（通常使用 window.setInterval()），但我们只能因地制宜地使用。把它用在动画上是合理的，但对于其它方面我们就必须仔细斟酌了。最显而易见的危险信号就是使用定时器来监视请求的完成。这种情况下应该使用回调而不是轮流监测的方式。

在回调中没有检查返回结果。在使用 XMLHTTPRequest 对象的 processReqChange() 回调时，必须对回调参数的 readyState 和 status 值进行检查。回调常常会在结果完成之前被调用。假如没有检查此结果，在代码试图处理不完整数据时可能会引起错误。

在传递 HTML 更合适的情况下，传递复杂的 XML。将 XML 格式化成浏览器中显示的 HTML 可能需要编写大量的 JavaScript，这可能导致开发人员不得不面对更多的浏览器兼容性问题。

就和你做所有事情一样，到底该在服务端还是客户端处理的选择应该根据工作的需求而定。在这种情况下，举一个相对简单的例子：给出一个电影列表。如果工作更复杂一些的话——可能包含排序，添加或删除，或者进行动态交互，在点击某个电影的时候显示更多的信息——那么在客户端将包含更复杂的代码。实际上，在本文结尾，我将演示如何对在客户端排序，探讨将负载过多地置于服务端的驳论。

在该传递 JavaScript 代码时，传递 XML。简而言之，在你可以使用 JSON 时不要用 XML：

这里的好处是显而易见的。在本例中，使用 JavaScript 语言客户端下载的数据量节省了 52%，并且性能上也得到提升，读取 JavaScript 版本速度快了 9%。尽管 9% 看起来并不多，不过要注意的是这个例子还尚未完善。更为庞大的数据块或者更复杂的结构将会带来更多的 XML 解析代码，而 JavaScript 则会保持不变。

在服务端进行过多处理。简单的单页面功能，如表格排序，在 JavaScript 中处理起来比服务端处理得更快，效率也更高。