4 ms·
As I mentioned in the comments, those examples aren't actually equivalent, the callback version could be: var getData = function(callback){ showLoa
by ollysb 13y ago
As I mentioned in the comments, those examples aren't actually equivalent, the callback version could be:
var getData = function(callback){
showLoadingScreen();
$.ajax("http://someurl.com", {
complete: function(data){
hideLoadingScreen();
callback(data);
}
});
};
var loadData = function(){
getData(doSomethingWithTheData);
}
var doSomethingWithTheData = function(data){
//do something with data
};
- tyleregeto 13y agoExactly. This is the problem I have with the hype around the promises API, and if you're a Dart developer, Futures. They claim to solve "callback hell" but they can't. Callback hell is the result of poor programming style, not a limitation of the language. Callback hell is just as possible with promises, and there are plenty of examples of it on the internet. I'm not saying promises don't have benefits, and can't result in some nice programming patterns, but generally they are just a different way of doing the same thing. It's not that callbacks are more tightly couples then promises, its that people write their code that way. Their API's have some other nice benefits though.
- rubiquity 13y agoI think Callbacks, Promises and Futures are all more or less the same in terms of coupling. However, I do find Futures to produce the most readable code.
- woah 13y agoI would agree. I've found, in my own code at least, that callback hell only happens with code that is not modular enough. If you separate your logic out into small self-contained modules that do one thing, they never get too deep. Promises allow you to have monolithic code that's not superficially ugly.
- icambron 13y agoYup. I actually adore promises, but I don't buy the decoupling argument at all. And the thing I keep seeing about how promises let you decide what to do with the data after you make the call as opposed to before seems...totally silly, since I had to make that decision when I wrote the code.
- sanderjd 13y agoWhen people say "later", they don't mean in human time, they mean in program execution time. As in, your program can decide based on the dynamic state of the system how (or even whether) to use the resolved value. In my experience, that is not nearly as convenient to do with callbacks as it is with promises.
- icambron 13y agoLater in that sense isn't usually very useful, since if the promise isn't resolved, there's no new information about the state of the system. Where I think promises help is that they allow to express the concept of "do stuff later" in a cleaner, more extensible way. It's really just about having a nicer interface (you can even ask it questions like, "what's been done?"). But the part where you decide what the promise will do after you specify what it's a promise for isn't, in my view, an important detail.
- sanderjd 13y agoI think we actually agree. Deciding "later" to do nothing is exactly the type of decision I'm talking about.
- ollysb 13y agoember-data is a great example of why promises can be useful. When a view is loaded you query your server for the model(via ember-data's api), but at this point what you get is a graph of unresolved promises. It then gets passed through to the controllers/templates etc. which render immediately but are then updated automatically as soon as the promises resolve. This is the real value of promises, you can pass them around your app before they're resolved.