PreloadJS has evolved quite a bit since it was first introduced, and due to browser quirkiness, a huge effort has gone into edge-case handling, which has caused the code to become somewhat complicated in places. For the upcoming CreateJS release, we have taken an opportunity to address this complexity, and completely re-architected the inner-workings of PreloadJS. Our goal was to ensure that 99% of the high level code that is in production today will be unaffected by dropping in a new version, so these changes have been made with this in mind.

One of the key updates is that in place of the two internal loaders that were used in previous versions – an XMLHttpRequest (XHR) loader, and a HTML tag-based loader – PreloadJS now uses content-specific loaders; each responsible for a specific content type. These loaders, such as ImageLoader, TextLoader, etc, are now only responsible for loading a very specific type of content, and as a result, the internal workings are much simpler. This has added some overhead in terms of the number of files (PreloadJS now has package directories like EaselJS as a result), but we think this is a minor trade-off for maintainability.

With this new approach, a single loader can be used without a LoadQueue:

var loader = new createjs.ImageLoader(loaderObject);
loader.on(“complete”, handleImageLoaded);

This takes a lot of the heavy lifting out of the LoadQueue class, and enables PreloadJS to do some other things:

• The LoadQueue no longer manually determines the loader to used. Instead, loaders decide if they want to handle the content on-demand.
• Loaders can load sub-content as part of their overall load.
  Additional “plugin” loaders can be used to provide custom loading. SoundJS has been rearchitected to inject custom audio loaders where necessary to support Flash and Web Audio.
• Individual loaders that are not needed for a project can be removed from PreloadJS minified builds (using the build process in GitHub) to reduce download time, and simplify the library to only include what you need.

Some additional classes that might come in handy are the XHRRequest, which provides a simple XHR-based load, and TagRequest, which provides a straightforward HTML tag load (such as scripts, images, etc). These can either be used standalone, or composed in custom loaders.

Hopefully this re-architecture will provide better maintainability, faster iteration, new capabilities, and reduce issues with edge cases introduced by some browsers (we’re looking at you HTML audio).

Check out the latest version in the “ExtendReArch” branch in GitHub. Hopefully we will be merging this into master in the next few days in preparation for the December 12th release!