0.6.0PreloadJSはこれまでブラウザごとの違いやくせをうまく扱うため、コードがあちこち複雑になってしまいました。Loaders」参照)。今PreloadJSを使って書かれているハイレベルなコードの99%が、新たなバージョンになっても問題ないことを目指しました。大きな変更のひとつは、ローダーの構成を変えたことです。これまでのバージョンは、内部的にXMLHttpRequest(XHR)とHTMLタグベースのふたつのローダーを用いていました。新しいPreloadJSでは、コンテンツごとにその形式に応じたローダを使います。ImageLoaderはイメージファイル、TextLoaderならテキストファイルというように、それぞれは特定のコンテンツだけを読込みます。そのため、内部的な仕組みはとても簡潔になりました。そのため、クラスファイルの数は増え(図001)、EaselJSのようにパッケージディレクトリを設けることになりました。メンテナンスの手間が少し増すだけでしょう。ImageLoaderクラス」参照)。handleImageLoaded);こうして、LoadQueueクラスは面倒な仕事を引受けてもらえます。すると、PreloadJSはほかのことに力が回せるのです。LoadQueueが使うローダーをいちいち定めなくて済みます。それぞれのローダーが、必要に応じてそのコンテンツを扱うかどうか決めればよいからです。ローダーは、ロードすべき内容の一部のコンテンツを読込むこともできます。特別なロードのために追加のプラグインローダーを用いることもできます。Audioがサポートできるよう仕組みを改めました。プロジェクトで使わないローダーがあれば、コンパクト化する(min版)PreloadJSから除いてしまうこともできます(GitHubでビルドします)。すれば、ダウンロードは速くなり、ライブラリに必要なものだけが含まれます。あと、よく使われそうなクラスが、XHRRequestとTagRequestです。前者は、基本的なXHRベースの読込みを行います。後者は、HTMLでスクリプトやイメージなどを読込みます。これらのクラスは単独でも、組合わせてカスタムローダーでも使えます。この再設計によって、メンテナンスしやすくなり、数の多い処理を速め、新たな使い途が広がり、HTMLオーディオなどのブラウザ特有の問題が減ることを期待します。フレームワークは、まずバージョンの異なるライブラリ間で結果を比べています(EaselJS「PerformanceTests」)。つぎに、コードとブラウザの描画を分けた結果が調べられました(EaselJS「FauxCanvas」)。フレームワークはまだできたばかりなので、これから充実させていくことになります。