Sebastian氏は、Ajaxフレームワークの選び方について書いている。彼は、アーキテクトが答えるべき多くの疑問を挙げている。それらは、コミュニティや企業のサポートや習熟のしやすさを考慮した上での、利用可能なフレームワークのリストを絞り込む時の手助けとなる。また、フレームワークは、そのサイトを訪れる人のタイプに応じて適合する。
彼の挙げた疑問点は次のとおりである。
Javascriptの構造の強化は？ あなたの開発チームが共通の開発手順を共有しないと、迷路のようなプログラムが出来上がってしまいます。Javascriptでは、同じことをするための実装方法がいくつも存在します。(例えば、DOMへアクセスするオブジェクトを作成する方法など)従って、実装方法を形式化する必要があります。そういったフレームワークは、オンデマンドなJavascript、パッケージ化、オブジェクト指向設計の促進等につながります。
一度作ったコンポーネントの再利用性は？ 一度作ったコンポーネントを次のプロジェクトで再利用することは、当然役に立ちます。
フレームワークにおける現在のドキュメント化のレベルは？多くのプロジェクトにおいてレベルが低いことがよくあるため、注意が必要です。
あなたの必要とする機能は？ 自身のプロジェクトでの現在若しくは近い将来のニーズを考え、フレームワークがそれらに対応しているかどうかを考えるかもしれません。そのニーズは、GUI、特殊効果や、Javascriptでの通信に関連するものであったりします。しかし、あなたの要求を完全にカバーするものは無いでしょう。よって、以下の点に注意する必要があります。フレームワークを拡張する際の、複雑な点はどこか？自分たちの機能をフレームワークに追加することができるか？コミッタのサポートはあるか？複数のフレームワークによるマッシュアップは可能か？
プロジェクトはどのくらいの期間か？ ほとんどのプロジェクトは、企業自身のプロジェクトのスピンオフです。フレームワークの進化は、プロジェクトが発展し、継続できるか次第です。機能の追加が必要になったときに開発者と話すことも大切ですが、よいユーザコミュニティというのも同様に大切なことです。スポンサーや、そのフレームワークが現在使われているWebサイトに気をとめておくことは、そのフレームワークがこの先も使われるのか、若しくは半年後には無くなってしまうのかを占う上で大切なことです。
Ajaxian上で議論されているその他の記事として、テスト方法やコード品質に関するものがある。
フレームワークを比較するための別のアプローチを、昨年12月のInfoQの記事でも取り上げているので参照されたい。
（原文は2007年3月21日にリリースされた記事です）