Curious about the reason you started from scratch
Closed this issue · 6 comments
Is there a particular reason while you would started your own promise library from scratch vs. leveraging the work of an existing one (like q or the very well-crafted bluebird)?
I do think breaking down Mongoose in smaller modules is a great idea, but I'm curious why you did not want to leverage proven existing work.
I believe this library started as a utility for the mongoose project, long before Q / BlueBird / when became so well established. Then it was spun-off for modularization sake.
There is a WIP in mongoose to move to a different library - Automattic/mongoose#1699
IMHO, tiny A+ promise implementation like mpromise is better suited to be embedded into another project, not specialized on promises.
when and Q libraries are full-fledged promise-based solutions for asynchronous control flow management. It makes them irreplaceable for promise-based projects, but it also makes them very huge.
If your only goal is to add optional promise support with minimal overhead then it's natural to choose some minimalistic implementations like mpromise or then/promise.
@lbeschastny I would pick performance and testing every time over payload size for NodeJS.
Regarding performance, have a look at this article.
But you said promises are slow!
Yes, I know I wrote that. But I was wrong. A month after I wrote the giant comparison of async patterns, Petka Antonov wrote Bluebird. Its a wicked fast promise library, and here are the charts to prove it.
| file | time(ms) | memory(MB) |
|---|---|---|
| callbacks-original.js | 316 | 34.97 |
| callbacks-flattened.js | 335 | 35.10 |
| callbacks-catcher.js | 355 | 30.20 |
| promises-bluebird-generator.js | 364 | 41.89 |
| dst-streamline.js | 441 | 46.91 |
| callbacks-deferred-queue.js | 455 | 38.10 |
| callbacks-generator-suspend.js | 466 | 45.20 |
| promises-bluebird.js | 512 | 57.45 |
| thunks-generator-gens.js | 517 | 40.29 |
| thunks-generator-co.js | 707 | 47.95 |
| promises-compose-bluebird.js | 710 | 73.11 |
| callbacks-generator-genny.js | 801 | 67.67 |
| callbacks-async-waterfall.js | 989 | 89.97 |
| promises-bluebird-spawn.js | 1227 | 66.98 |
| promises-kew.js | 1578 | 105.14 |
| dst-stratifiedjs-compiled.js | 2341 | 148.24 |
| rx.js | 2369 | 266.59 |
| promises-when.js | 7950 | 240.11 |
| promises-q-generator.js | 21828 | 702.93 |
| promises-q.js | 28262 | 712.93 |
Most important to me is debuggability.
BTW: any chance someone throws mpromise into the mix? it does get downloaded ~ 30,000 times a month...
this was the result of specific needs for mongoose and the other libs didn't support quite the right features (EventEmitter based with custom event names). I'm not a fan of adding more features to this lib. The goal was to be Promises A+ compat so it works with the other popular libs. Wouldn't mind swapping out this for Q or bluebird etc within mongoose. Very doable with some light shims. mongoose-bluebird, mongoose-q or something.