I can understand the confusion about the naming part. We’ll look into that.
@Bart: good post. by default there is just one request, which loads the file, so I think you misunderstood what happens.

We do however offer the possibility to use a combination of a Sequence and a Loader to be able to fetch the header of the file which contains the filesize, so you can accurately get the total byte size of the files you are about to load. In that way, you can get accurate loading progress without knowing the filesize in advance, it does however need a littlebit of extra time when starting the loader to ‘touch’ the files. The Sequence and Tasks are part of our package and we like to use building blocks with which we can create different functionality, which is one of the things OOP allows you to do. In this way, we did not have to burden our Loader with this functionality, while at the same time allowing it to happen with the use of another specialized package.

About filesize, we use the package as is, and it is not optimized for a small footprint since we use most of the classes in it in our projects. LoaderMax has been made with a small footprint and no dependencies, our Loader is just a part of this Library. I’m not sure if LoaderMax is tested, but our package is unittested and as such we build on components that work and have proven themselves.

LoaderMax seems to have the same functionalities as we do, but we hadn’t heard of it before, since we’ve been using the Loader itself for quite some time now, it seems LoaderMax is fairly new? Both packages seem to be able to do about the same but I’m not sure if LoaderMax has object association with it, the ability to have data associated with a loading item. Also, we also have a simple asset manager that integrates with the loader.

I feel our api is simpler since you don’t burden the client of our code with the knowledge of which loader to instantiate, the api is conform a lot of other classes in our package which makes it very consistent, it is better in OOP setup, since it doesn’t concern itself with how the loaded content is used (no DisplayObject association), but it CAN be done via object association. It can be extended and configured with new Tasks to suit your specific need but comes with sensible defaults for most use cases.

THe philosophy behind the loaders is a little different but they can both have their place. A matter of preference and your use cases I guess.

Also naming it Loader is really confusing. I think its bad form to alias a native class (it’s technically correct with the packages, but using this in a smart editor like FDT will mess your auto-suggestion something horrid).

How is this better then LoaderMax or the arcane BulkLoader? Both are solutions that dont include a lot of extra code, while for this solution we’ll get the a huge chunk of the dpdk libary.