Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Curious about the reason you started from scratch #10

Closed
mgcrea opened this issue Mar 15, 2014 · 6 comments
Closed

Curious about the reason you started from scratch #10

mgcrea opened this issue Mar 15, 2014 · 6 comments

Comments

@mgcrea
Copy link

mgcrea commented Mar 15, 2014

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.

@refack
Copy link
Collaborator

refack commented Mar 15, 2014

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

@mgcrea
Copy link
Author

mgcrea commented Mar 15, 2014

@refack Thanks for the quick answer.

@mgcrea mgcrea closed this as completed Mar 15, 2014
@lbeschastny
Copy link
Contributor

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.

@mgcrea
Copy link
Author

mgcrea commented Mar 15, 2014

@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

@refack
Copy link
Collaborator

refack commented Mar 15, 2014

Most important to me is debuggability.
BTW: any chance someone throws mpromise into the mix? it does get downloaded ~ 30,000 times a month...

@aheckmann
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants