Loader without async

[vlucendo]

Hello,

Currently resource-loader uses the queue and eachSeries of the async library, but still the minified build is pretty big (64kb).

Would it be possible to make a loader plugin for fae based on resource-loader but using promises instead of async?

For example eachSeries could be replaced by:

const funcs = [foo, bar, baz, qux]; //promise factories

let f = funcs[0]();

for(let i = 1; i < funcs.length; i++)
    f = f.then(funcs[i]);

f = f.catch(function(e){ /*handle error*/ });

async.queue usage is to limit the concurrency right? There are packages on npm or libraries like bluebird that show examples of how to implement this with a few lines.

Promises may not be as performant as async but a loader is not something where an extra couple hundred operations per second matter anyway.

[englercj]

Just bluebird core is ~50Kb, and it would have to ship with it since we would need the polyfill. I don't think promises buy us anything in terms of file size. Additionally, I avoid promise-based APIs in libraries because it is infectious. Using promises in one place makes it difficult to not use them everywhere, whereas callbacks don't do that.

async.queue usage is to limit the concurrency right? There are packages on npm or libraries like bluebird that show examples of how to implement this with a few lines.

I don't think this is true. An async queue that executes in series is trivial, an async queue that has concurrency and doesn't allow additions during execution isn't too hard, but an async queue that does both is actually non-trivial but not prohibitively difficult.

I analyzed the bundle file using disc and here is the output: disc.zip.

Looks like the reason that the async queue is so large is due to lodash dependencies. Replacing async usage with something like d3-queue might make sense to reduce that file size, but that module doesn't allow additional tasks to be added after the queue is processing. I will probably just make my own.

Additionally, it looks like the url shim provided by browserify is of non-trivial size and so is its dependency punycode. Something like url-parse might be smaller if I used that instead?

Anyway I'm going to move this conversation to the resource-loader repo and will try some of these things out to reduce file size.

[vlucendo]

You're right, I wasn't aware about the posibility of adding tasks to the queue during execution. And yeah, the use of a polyfill (even a small one) would be neccesary with the promises approach.

I've been using resource-loader often and only recently checked the size of the build. After reading your comment I believe your alternative is the right one :)

[englercj]

Thanks for being understanding, I'm looking into reducing the file size now with englercj/resource-loader#67. Hopefully I can have something soon that save some significant size.