JSAN（http://www.openjsan.org/）とDojo（http://www.dojotoolkit.org/）の比較、JSANとDojoを一緒に使う話などは、なかなかに興味深いので、調べがついた順に記していくことにします。（おおざっぱな概要は昨日書きました。）
昨日、「JSANがPerl風、DojoがJava風」と書きましたが、JSAN.jsが明らかに「Perlの仕掛けを再現しよう」としているのに対して、dojo.jsがJavaのエミュレーションを試みているわけではありません。requireとprovideのペアは、むしろLispのフィーチャ管理系に似せているようですし。
とはいえやっぱり、Dojoは文化的にはJavaの（もちろん、JSANはPerlの）影響下にあるように思えます。Dojoは、包括的でよく統制されたライブラリ／フレームワーク一式をDojo Foundationの制御下で構築しようとしているようです。「Dojo Toolkit : Dojo Foundation ≒ Java : Sun Microsystems」という感じかな。政治的／ビジネス的に囲い込みの意図はないにしても、アーキテクチャルな統合への意図（意志）を感じます。
一方のJSANは、役に立つコードをとにかくかき集めて一カ所にまとめておこう、というアーカイブ／リポジトリ志向ですね。モジュラリティを実現する最小のインフラ（それがJSAN.js）は準備するが、全体としての統制や一貫性とは無縁です。
JSANアーカイブに集まっているモジュールには、既存のコードの一部を切り取ってまとめたものがあります。例えば、DOM.*、Class.*、Function.bind などは、prototype.jsから切り取ったものです。MochiKit（http://mochikit.com/）もJSANに入ってますが、これはDojoとJSANに対応しようとしているようです（see ↓）。
if (typeof(dojo) != 'undefined') {
dojo.provides('MochiKit.MochiKit');// 's'はいらないよ (檜山)
dojo.require("MochiKit.*");
}
if (typeof(JSAN) != 'undefined') {
JSAN.use("MochiKit.Base", []);
JSAN.use("MochiKit.Iter", []);
JSAN.use("MochiKit.Logging", []);
JSAN.use("MochiKit.DateTime", []);
JSAN.use("MochiKit.Format", []);
JSAN.use("MochiKit.Async", []);
JSAN.use("MochiKit.DOM", []);
JSAN.use("MochiKit.Visual", []);
}
DojoとJSAN、どちらの方針がよいかは、用途、価値観、趣味によりけりです。特定のアーキテクチャ／フレームワークにコミットしたくないなら、JSANのなかから適当なモジュールを探し出して組み合わせたほうがいいでしょう。しかし、複数のモジュールがうまく協調する保証は全然ありませんし、重複した機能（の異なる実現）を持っているかもしれません。
Dojoも一部分だけを利用することもできます。例えば、dojo.js（もとになるソースはsrc/bootstrap1.js）に含まれるユーティリティ関数は便利そうです。もっとも、心情的にJSAN寄りの僕は、dojo.jsを切り刻んでJSANモジュールに仕立てたくなってしまうのですが…
