Why use callbacks over 'return' for anything other than IO and waiting? If there's not two out of sync parties, there's no need to tell another person to call you back, and no advantage to performing an extra function call.
re: yummyfajitas: that does not use a callback, it returns a list. And if retrieveURL is nonblocking, then iteration is nonblocking.
Something I mention in the article/paper/whatever is using operations that are technically blocking to call functions that happen asynchronously. So there are certainly uses for sync iteration tools (like _.each())
I think it depends on where you put the async assumptions. Do you know/assume that the function itself takes care of the async aspects, or do you know/assume that the caller must take care to set up that structure?
If the answer is the former, then use whatever structure you want, because the async is taken care of for you. If the answer is the latter, perhaps you need a iteration function that works asynchronously.
_.each() is NOT blocking, anymore than "var x = 1" is blocking, "callback(error, result)", or asynchronous_operation(callback) is blocking. It introduces NO synchronous waits. It cannot magically decompile your nonblocking system calls, and recompile them as blocking system calls or insert "while(true)"s. You have to explicitly add the blocking code yourself.
> Do you know/assume that the function itself takes care of the async aspects, or do you know/assume that the caller must take care to set up that structure?
It's still nonblocking. Whether one figured out how to pass all the parameters to a function and complete their intended code is a different question then whether or not completed code is blocking. Is this code blocking? == Does this code introduce undesirable synchronous waits and stalls?
Seriously, write a simple C program and prove all of this to yourself.
You cannot interrupt "var x = 1" and you cannot interrupt a javascript forEach while it is looping over an array. With a really large array this is going to cause problems, like that infamous fibonacci example.
Seriously, try it. It's not like a C program.
However, by having a callback interface the caller doesn't need to know whether a particular call involves IO or not - and you're also free to introduce IO if needed.
A useful example would be using some sort of 2 level caching, where some stuff is in memory, and other things are in a persistant store out-of-process.
Also, consider the following as an example of a use-case for a callback/async aware map function
async.map(list_of_ids, fetchURLFromAPI, function(err, urls) { request.respond(urls.join(",")); })
_.map(listOfURLs, retrieveURL)