Using just promises with a good library will off course already give you the asynchronous callstacks / error propagation. So it's really only the coroutines that are improving readability / maintainability, but you can't have coroutines without promises, or some sort of abstraction around callbacks.
On 16 April 2014 15:26, willem dhaeseleer <[email protected]> wrote: > Charlie, > > I actually agree that promises them self don't really contribute to much > to the readability of code. > It's only when you combine them with generators to create co-routines that > you truly benefit from improved readability and asynchronous callstacks / > error propagation which can be really helpful during debugging as well. > > > > > > > > > On 16 April 2014 15:05, Charlie McConnell <[email protected]>wrote: > >> I would like to argue with the increase in readability - it doesn't >> exist. >> >> Promises are an overly verbose "solution" to a simple problem, and are >> not an appropriate global replacement for callbacks in every case. Saying >> so is misleading and disingenuous. >> >> If you want something universally usable, use callbacks, and let the >> consumers of your library wrap them in all the promises they want to. >> Wrapping a callback in a promise is less work than taking apart a promise >> into a callback, making this the most widely useful approach. >> >> Using solely promises is only going to contribute to the increasing >> fragmentation of this community into sects, each revolving around its >> (primarily cosmetic) abstractions of choice. >> >> -- >> Charlie McConnell >> >> >> On Wed, Apr 16, 2014, at 03:34 AM, willem dhaeseleer wrote: >> >> That fact that node core api's only support callbacks doesn't make them >> holy. I understand they used callbacks back in 2009 before >> the proliferation of asynchronous control flow in javascript and the state >> of promises in V8 / ECMAScript . But today promises are in V8 and wildly >> used and you just can't argue with increase in readability, maintenance and >> productivity. >> I'm sure we could have a lengthy discussion about what makes a good api, >> but I think most people will agree with me that consistency should be key. >> Providing both promises and callbacks in your api seems like a very bad way >> to go. >> >> The node core API also doesn't really define a *standard*, it defines an >> interface, I believe there are even some methods in the api that don't even >> respect the *callback(err, >> result)*<http://nodejs.org/api/fs.html#fs_fs_exists_path_callback> format. >> >> The standard is ECMAScript, and ECMAScript 6 has promises, and >> generators, use them where applicable. >> >> >> >> >> >> >> >> On 16 April 2014 12:02, greelgorke <[email protected]> wrote: >> >> my only concern about your post is that you simply ignore the standards >> in node. node core apis are callback based, your 3rd party libs should >> honor this. a good api doesn't care much about personal opinions and a) >> supports the standard and b) provides optional methods for convinience. >> >> it's not about whats better. its about what a good api >> >> Am Mittwoch, 16. April 2014 10:27:18 UTC+2 schrieb willem dhaeseleer: >> >> >> Hey greelgorke, >> >> Great to get some feedback on my answer, I'll try to clarify my arguments >> some more here: >> >> >> - It always you to pass on asynchronous operations >> >> huh? >> >> // foo returns promise >> var futureBar = foo(); >> >> // you can know pass around futureBar to some other api or use it for >> later reference >> // with callbacks you will have to write your own wrapper code to get >> this type of "asynchronous encapsulation" >> >> >> - How many types have you typed *if (err) throw err *or *if (err) >> console.warn(err) ?* >> >> you actually type this yourself? >> >> Off course not, but i have seen it in to much code already. >> Obviously i forgot* if (err) return callback(err);* >> If haven't written in this style anymore for a long time. >> >> >> - Improved readability trough more logical control flow >> >> duh. readability is subjective. >> >> Off course it's subjective, but chronological reading order is something >> I tend to value in most code. >> Just my opinion. >> >> >> - Integration with coroutines ( you want this ) >> >> huh? how is that connected? >> >> An example should clarify this, this uses bluebird: >> This is obviously a bad use of a database, but the idea is to demonstrate >> how promises integrate with coroutines. >> >> >> var getTotalFriendBalance = Promise.coroutine(function* (name) { >> var user, userFriends, x, totalBalance; >> user = yield db.getUserByName(name); >> userFriends = yield db.getFriends(user.id); >> for (x = 0; x < userFriends.length; x++) { >> totalBalance += (yield db.getAccountInfo(userFriends[ >> x].id)).balance; >> } >> return totalBalance; >> }); >> >> >> I challenge you to write this peace of code with only callbacks, I think >> you will find this syntax is much more intuitive and more pleasant to write. >> This is only possible because all asynchronous methods here return >> promises (or thenables) that can be used by the coroutine. >> >> I hope this clarifies my personal opinion on why promises are better. >> >> >> >> >> On Wednesday, April 16, 2014 9:50:22 AM UTC+2, greelgorke wrote: >> >> inline >> >> Am Mittwoch, 16. April 2014 08:46:48 UTC+2 schrieb willem dhaeseleer: >> >> >> Andrew, >> >> For the love of all that is dear to us, Use promises, do not support >> callbacks, don't even think about supporting both. >> There is a reason why promises are becoming part of the standard in ECMA >> 6. >> >> >> they are there to give you an alternative, not a replacement. Callbacks >> are simple for simpler things. they are the core pattern and they are >> accepted. every single person new to node, can just use them, as soon she >> understood async coding style. >> >> it is a very bad habbit to only provide promises api. one of the top3 >> popular modules on npm is async, which handles callbacks. >> >> So, stop crying about callbacks, learn them and provide a cb-based >> interface. and stop saying us. :P >> >> >> >> Here are a few of many reasons why to choose promises: >> >> - It prevent deep indentation >> >> flatten your code. >> >> - It always you to pass on asynchronous operations >> >> huh? >> >> - Asyncronous callstacks and consistent error handling ( you want this ) >> - How many types have you typed *if (err) throw err *or *if (err) >> console.warn(err) ?* >> >> you actually type this yourself? >> >> - Refactoring in callback styled code is extremely tedious to the point >> where it would be almost reasonable to say it's impossible >> >> it always hard to refactor bad written code either with callbacks, >> promises or even synchronous code. >> >> - Improved readability trough more logical control flow >> >> duh. readability is subjective. >> >> - Integration with coroutines ( you want this ) >> >> huh? how is that connected? >> >> >> >> >> On Tuesday, April 15, 2014 6:20:05 AM UTC+2, Andrew de Andrade wrote: >> >> So at work we're working on a bunch of node modules that will eventually >> be published as open-source and I'm in favor of callbacks and two of my >> co-workers are in favor of promises. We've discussed supporting both API >> interfaces and I was curious what the general consensus of the community >> was with respect to supporting both and the best way to name functions and >> methods to support both. >> >> That being said, there are three obvious choices: >> >> (a) two function types: (1) synchronous functions; and (2) async >> functions that return promises but also handle callbacks >> >> var value = myFunctionSync(); >> myFunction(callback); >> var promise = myFunction(); >> >> this approach has a tiny performance overhead (since you have to check if >> the last argument is a function to determine if you should return a promise >> or execute that function as the callback) and makes all the functions a >> little convoluted (unless you make one higher order function that you apply >> to all your callback functions to support both APIs). Furthermore async, >> higher order, overloaded functions or variable arity functions become >> impossible since you can't necessarily assume that the last argument is >> always the callback. >> >> (b) three function types: (1) synchronous functions; (2) async callback >> functions; and (3) async promise functions >> >> var value = myFunctionSync(); >> myFunction(callback); >> var promise = myFunctionDeferred(); >> >> this is ugly but explicit in terms of what to expect and permits the most >> flexibility. >> >> (c) two function types: (1) synchronous functions; (2) async callback >> functions; >> >> var value = myFunctionSync(); >> myFunction(callback); >> >> and promise support is left up to the user by using a nodeify() method >> from a promise library. This is my preference, but won't make my co-workers >> happy. >> >> >> With all this in mind, what's the general consensus of the NodeJS >> community on this issue? I searched google and the archives and could not >> find any blog posts or discussions that address this particular issue. What >> are the pros and cons of each approach? What if any libraries implement >> options (a) or (b)? etc. >> >> >> >> >> -- >> -- >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/NpZ4WT1eOnw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> -- >> -- >> 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/d/optout. >> >> >> -- >> -- >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/NpZ4WT1eOnw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- 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/d/optout.
