Escape from Callback Hell • Hacker News Board

Re: Escape from Callback Hell

#51

Post by lucian1900 » Sun, Mar 03, 2013, 11:26 AM UTC

bestest wrote: post #13

Well, frankly, it looks like you're jumping from one sheep to another. Using deferreds does NOT make more sense, and is actually even more difficult to perceive as it's quite counter-intuitive. MVVM is the way to go for web apps. Actually, anything else would be better than this. The methods and approaches jQuery provides should not be used as a mainframe to achieve your goal, they should only be used as helpers here…

The deferred monad is pretty much the standard way to deal with this problem and it composes nicely. Have a look at Twisted's.

Re: Escape from Callback Hell

#52

Post by daleharvey » Sun, Mar 03, 2013, 11:30 AM UTC

Too wrote: post #41

daleharvey wrote: post #26

Earlier quoted context omitted.

That isnt the point, its that you have some nice code that does |var x = someBigFunction()| and at some point in the programs life, something inside someBigFunction turns async, you have a whole restructuring to do.

Then that's a breaking change of the someBigFunction()s interface and it should be treated with care, not just quickly patching on a promise and hope for the best. Javascript is single threaded so when you wrote someBigFunction() you didn't have to think of parallel side effects. If you suddenly pause the execution of someBigFunc() and allow the user to mess around with the interface, the global state that someBigFun…

The fact that I changed a calculation from a constant to reading its value from indexeddb shouldnt need to be an intrusive change. It is makes things more likely to break, there isnt some 'oh you decided to do io so you deserve to do a big refactor' point

Re: Escape from Callback Hell

#53

Post by jj2 » Sun, Mar 03, 2013, 12:48 PM UTC

If you have to deal with lots of nested callbacks, it's probably worth to use a CPS transformation like Streamline.js. It makes your code a lot cleaner. As if it was written synchronously.

https://github.com/Sage/streamlinejs http://en.wikipedia.org/wiki/Continuation-passing_style

Re: Escape from Callback Hell

#54

Post by ajanuary » Sun, Mar 03, 2013, 1:04 PM UTC

Too wrote: post #42

function getItem(id) { return $.get("/api/item/" + id); } $.when(getItem(3), getItem(4)).then(handleSuccess, handleFailure); Maybe I'm taking the point of the example out of context here, but i worry that promises makes it too easy to write non thought through code like this. Why make two separate http-requests for something that should have been possible to do with one? Future prediction: Someone will create code si…

You frequently don't control the API's your hitting. I've seen plenty of API's that don't support bulk operations.

I'm not sure I'm convinced if someone doesn't know how to do a bulk operation they're more likely to look because they've got an extra callback or two.

Re: Escape from Callback Hell

#55

Post by ufo » Sun, Mar 03, 2013, 2:04 PM UTC

coldtea wrote: post #43

Swizec wrote: post #2

I honestly find "callback hell" a lot easier to follow and understand than the vast majority of fixes everyone is coming up with. They're just continuations, seriously, what's everyone's problem? You define a function, it gets access to the current scope, it defines the rest of the program flow. If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you d…

> They're just continuations, seriously, what's everyone's problem? That they're badly made continuations, without support from the language. > If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you don't get access to the current scope. At the cost of moving stuff out of where it's invoked, so making code harder to read. The problem with callback hel…

My favourite example of this is loops. Its very annoying to put an async call inside the loop since you need to rewrite the loop as a recursive function.

Re: Escape from Callback Hell

#56

Post by ufo » Sun, Mar 03, 2013, 2:07 PM UTC

jart wrote: post #24

My favorite solution to this problem is a thing the OKCupid developers made called IcedCoffeeScript http://maxtaco.github.com/coffee-script/

Do you know if there are any good alternatives that are pure-ish JS? I know that same guy worked on tamejs but they don't seem to be working on that anymore...

Re: Escape from Callback Hell

#57

Post by ufo » Sun, Mar 03, 2013, 2:16 PM UTC

rorrr wrote: post #39

> "This is better, it definitely makes it clearer what exactly is going on" function createItem(item, successCallback, errorCallback) { var req = $.post("/api/item", item); req.success(successCallback); req.error(errorCallback); } How is this more clear than the default jQuery $.post?

Not really better. The advantages of promises show up when you pass promises around, letting other people add their callbacks to it (this way the "callback structure" is implicit from the program flow, just like what happens when you do normal sync programming. Another advantage of promises is that they have some better support for error handling (you don't need to thread the error handler around and you "throw" statements are caught correctly)

Honestly, I didn't like the examples in the article very much. Not only do they fail to show the major advantages promises have, but he also uses named functions everywhere and that is quite silly.

Re: Escape from Callback Hell

#58

Post by ufo » Sun, Mar 03, 2013, 2:21 PM UTC

spion wrote: post #46

If you want this problem solved, vote on the generators issue in v8: http://code.google.com/p/v8/issues/detail?id=2355 If v8 implements this, both Firefox and Chrome as well as node.js will have yield, enabling libraries like taskjs [1] to be used. From taskjs.org: spawn(function*() { var data = yield $.ajax(url); $('#result').html(data); var status = $('#status').html('Download complete.'); yield status.fadeIn().pro…

Does anyone here have experience with using one of those X-to-JS compilers that do a similar thing but without requiring those Javascript extensions? The only one I hear people talking about a lot is icedcofeescript but I'm not a big cofeescript fan...

Re: Escape from Callback Hell

#59

Post by moe » Sun, Mar 03, 2013, 2:54 PM UTC

If only someone could come up with an abstraction over all this... We could perhaps call it threads, or co-routines, or such. It could make things so much easier!

Re: Escape from Callback Hell

#60

Post by ianbishop » Sun, Mar 03, 2013, 2:54 PM UTC

rorrr wrote: post #39

> "This is better, it definitely makes it clearer what exactly is going on" function createItem(item, successCallback, errorCallback) { var req = $.post("/api/item", item); req.success(successCallback); req.error(errorCallback); } How is this more clear than the default jQuery $.post?

Agh, this is an editing mistake. I re-worded this last minute and reading again next day, it was a mistake.

Really what I meaning to say is that it's much clearer as to what is happening. I was trying to point out that success and error were actually functions on the deferred returned from $.post, not just functions you can pass into $.post (as they once were - hence "circa 2009").