現場でAjax開発での仕事での経験をもとにして、Jack Herrington氏が、アンチパターンとしてあげるのにふさわしい5つの特別な問題を集め、Ajaxコードの落とし穴を掘り下げて書いた。要約は次のとおりである。
必要が無いのにタイマーをポーリングする JavaScriptには、タイマー関数があります(通常、window.setInternval()を使用します)が、慎重に使用されるべきである。アニメーションには有効だが、他の用途で使用する際には、十分にチェックしなければいけない。赤旗として注意が必要なものの一つとして、リクエストが完了したことを監視するためにタイマーを利用することである。ポーリングではなく、コールバックを使用しなければならない。
コールバックの返り値をチェックしない XMLHTTPRequestオブジェクトのコールバックをprocessReqChange()で行う際、コールバック結果であるreadyStateプロパティとstatusプロパティのチェックを行う必要がある。コールバックは、大抵、結果が完了する前に呼ばれるだろう。不完全なデータの処理を行おうとするときにチェックをしないと、エラーが発生する。
HTMLの方が良いとき、XMLの複合とする ブラウザで表示するためのHTMLの中に整形したXMLを書くことは、多くのJavaScriptを必要とし、開発者をブラウザの整合性問題にさらすことになる。おおまかなものは次のとおりである。
一連のこととして、ジョブの要求によって、サーバ上で処理を行うか、クライアント上で行うかという選択があります。例えば、映画の一覧を表示するといった場合、ジョブとしては比較的単純です。もし、ジョブがより複雑(多分、ソート、検索、登録、削除、若しくは、ある映画をクリックすると追加情報が表示されるような動的なインタラクションを伴うもの)ならば、クライアントのコードはより複雑なものとなります。事実、私はこの記事の最後で、処理をサーバに置いた方が良いという反論について語るにあたり、クライアント上でのソート処理のデモを行うでしょう。
JavaScriptコードを使用する際にXMLを使用する 簡単に言えば、JSONが使えるときはXMLを使用しないということである。
そのメリットははっきりしています。例として、JavaScriptコードと一緒に、クライアントにダウンロードしたデータの塊のサイズの52%を保存しました。さらに、パフォーマンスがアップしました。JavaScriptバージョンを読んだ方が、9%高速でした。9%はさほど大きくないように見えますが、これはかなり基本的な例だということを念頭において下さい。より大きなデータブロック、若しくは、より複雑な構造の場合、JavaScriptコードは変わらないままですが、XMLをパースするコードがさらに必要になるでしょう。サーバで沢山のことをしない 表をソートするような単純な単一ページでの機能の場合、サーバよりもJavaScriptの方が、より高速で、効率よく処理することができる。
（原文は2007年3月31日にリリースされた記事です）