Why not use cujojs/when ? about asyncfuture HOT 4 CLOSED

Looks to me like some good reasons are:
A. Avoid bloat - when isn't just a future/promise library. If you don't need 95% of the stuff in when, then there's no reason to bloat your web packages.
B. Simpler API - for similar reasons to the above
C. Looks like asyncFuture matches try-catch-finally semantics a little closer than when does, for example, in asyncFuture finally always passes through the resolution of the calling future, while in 'when' there is no way to propogate the value of the calling future (that's pretty bad design if you ask me).
D. Also, I see no straightforward way to resolve futures manually with 'when'. This is frequently necessary.
E. asyncFuture requires that you return a future from then, catch, and finally blocks, because of the edge case where you want to return a future of a future. You shouldn't have to know what kind of value you have to be able to propogate it in a future chain.

Then again, 'when' supports non ES5 environments, whereas asyncFuture doesn't at the moment.

from asyncfuture.

@sompylasar Just added a performance comparison, and it turns out async-future is pretty much the fastest promise library! I'm pretty surprised actually, but it sure feels good : ) . When.js is also one of the fastest, and of course benchmarks have to be taken with a grain of salt, but its another minor reason to use it over when. Unless you're using IE. When.js seems to be slightly faster in IE11 for some reason.

from asyncfuture.

from asyncfuture.

I think the only thing i'm missing there is full test coverage for a wide set of browsers. Would definitely appreciate any help on that front. Thanks for the interest

from asyncfuture.