Generalize the use of "promises", in order to simplify the code

[mossroy]

Basically, it replaces the callbacks with .then(doSomething);

https://api.jquery.com/promise/

[mossroy]

Hopefully it might simplify the "articles nearby" algorithm

[Jaifroid]

@mossroy @sharun-s , how necessary is the Q library now that all "modern" browsers support promises natively? I notice, @sharun-s, that you are experimenting with a version without Q. What is your experience? I'm wondering if we can remove some overhead. Does FFOS browser require Q?

[sharun-s]

I removed it cause the callstack would get filled with a bunch of calls to q making debugging async stuff complicated. So far so good though. That's on desktop, with most testing done on Chrome and Firefox. Edge I test once in a while and it seems to be fine there too.

[sharun-s]

Sorry hit the wrong button there.

[Jaifroid]

Thanks, @sharun-s . I've removed Q from the Kiwix-JS-Windows "Remove-Q" branch for testing whether it speeds things up. For the sake of documenting what's needed to remove it, the code starting from this point: kiwix/kiwix-js-pwa@aa7d933#diff-bca463ed8ccf5e2058dfe307a95e8501L26 , shows what's needed to remove it, with acknowledgements to @sharun-s for the substitutions. Will do some testing and report back.

[Jaifroid]

@sharun-s, @mossroy:

So, I've updated my timing document to test scenarios with and without Q. Excel spreadsheet here:
https://github.com/kiwix/kiwix-js-windows/raw/master/Timing%20tests%20Build%200.8.6%20with%20and%20without%20Q.xlsx .

The headline is that Kiwix JS does not run at all on Firefox OS without Q, in the simulator. I could find no way to make it run. So that is probably a block for removing Q at least while we support FFOS.

Second, performance in Firefox (desktop) actually drops on removing Q, in terms of absolute timings. -8.8% overall drop in performance when pulling CSS from the ZIM, and -11.2% drop just for the images. The performance is even worse without Q if we pull the CSS from cached assets (presumably because then the time to extract images becomes the predominant factor). Overall -19.3% drop in performance, and -24.1% for images.

On Edge desktop, performance without Q overall improves slightly +5.1% if pulling CSS from the ZIM. However, performance drops -3.5% if pulling CSS from cached assets.

On UWP Mobile, there is an overall gain of +11.9% without Q if pulling CSS from ZIM, but drop of -7.6% for images. There is an overall gain of +1.4% if pulling CSS from cached assets, but drop of -11.5% for images.

So, it's a mixed bag. On all systems, the UI subjectively feels less responsive without Q. For example, the spinner hardly ever spins while waiting for a page to load without Q, giving the disconcerting impression that the UI has frozen, for very large pages on slow systems. I'm guessing that this is because the native implementation jumps from one promise to the next while not "surfacing" to let code run in the main "thread" (I know there's actually only one thread).

So, my conclusion just based on these timings and overall subjective feel is that it would be detrimental to remove Q at this point in time. Q seems to be a smoother implementation of promises, with regard to UI responsiveness, than native promises in all three environments I tested. This could change drastically with Web Workers, however.

[mossroy]

@Jaifroid thanks a lot for this testing and benchmarks.
Based on your results, I agree with you that we should keep Q for now (and remove the use of native Promises).
In terms of compatibility, it would not work with IE and with the default browser of a not-so-recent Android : see http://caniuse.com/#feat=promises

[Jaifroid]

I think we are using Promises now wherever it was easy to insert them without significantly rewriting the back end, which is not a good idea while we see if #514 can be fully implemented. So I'm closing this issue, but, @mossroy, if you think we still need to work on Promises before implementing libzim wasm, please re-open.