> > Using callbacks in your own application code is the path of least > resistance for using the majority of value in the node ecosystem.
I am new to Node and trying to decide between promises, asynch and vanilla, there are so many good arguments for each. Mikeal, do you mind expanding further how using promises in your own, non-shared, code could hinder use of node? Do a lot of the libs that depend on asynch require you to use asynch as well (or make things easier if you do)? Best, Baz On Sunday, November 11, 2012 10:46:05 PM UTC-8, Mikeal Rogers wrote: > > It's great that you have a strong opinion. Here's some numbers: > > Here's the number of modules that depend on async and Q. > > async: 975 > Q: 109 > > Here are the numbers of downloads in the last month. > > async: 120,271 > Q: 33,242 > > > Some people clearly like promises, but the dominant pattern in node is not > promises, it's callbacks, with complex callback issues managed with async. > > Stating your opinion strongly does not make it a fact. This is your > preference, and many others, but not the majority. > > If you write a library, it better use callbacks if you want people to use > it. Using callbacks in your own application code is the path of least > resistance for using the majority of value in the node ecosystem. That's a > fact, there are numbers. It's not everyone's preference, but it's the most > popular by far. > > -Mikeal > > On Nov 11, 2012, at November 11, 20125:18 PM, Andy > <[email protected]<javascript:>> > wrote: > > To reply to my own very old thread after getting some solid experiences > with promises, the answers to my questions are: > > 1. *async* is a library that passes callbacks around. it's ugly and it > sucks. > > 2. a* promise *is just an object. Don't let anyone tell you differently, > they are just trying to confuse you. It's an object that has method names > that everyone's agreed on, like *then *and *done *which will magically > trigger your callbacks for you. With promises, you include *Q* and you > just pass around Q objects (called deferreds and promises). It's just that > everyone agreed that the promise object will have a *.then* method, which > you can call and your function jumps next in line onto the promise chain > magically. > > The libraries should *not *be used together. Once you get your head > around promises and use them in field you won't want to use anything else. > > If you are exposing an API, you should still take/call a callback. If > you're writing a database client you don't want to give the user a promise > and force them into your model. Just call their callback at the end of your > own, internal beautiful promise chain. It will be our terrible secret. > > Promises aren't perfect and can get strange when doing some complex > composition (lots of return statements to return promise chains), but they > make writing async code soooooo nice. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] <javascript:> > To unsubscribe from this group, send email to > [email protected] <javascript:> > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
