Live data from Hacker News

Callback Hell (2016)

callbackhell.com

91–100 of 170 posts

Re: Callback Hell (2016)

#91
This is where syntactic sugar can be helpful. CoffeeScript can make the example a lot more readable by removing the unnecessary braketing when the last argument of a function is a callback (common case in node.js). The only thing that's still ugly is the .bind() applied to a function, which somewhat messes with the style. Other than that, this makes callbacks flow a lot more naturally when reading source code.

(Of course, as it is for all stylistic considerations, it's a matter of taste, not absolutes.)

    fs.readdir source, (err, files) ->
      if err
        console.log 'Error finding files: ' + err
      else
        files.forEach (filename, fileIndex) ->
          console.log filename
          gm(source + filename).size (err, values) ->
            if err
              console.log 'Error identifying file size: ' + err
            else
              console.log filename + ' : ' + values
              aspect = values.width / values.height
              widths
                .forEach ((width, widthIndex) ->
                  height = Math.round(width / aspect)
                  console.log "resizing #{filename} to #{height}x#{height}"
                  this.resize width, height
                    .write "#{dest}w#{width}_#{filename}", (err) ->
                    if err then console.log 'Error writing file: ' + err
                ).bind this

Re: Callback Hell (2016)

#92
post #79

I think this is a fantastic article in many ways. It clearly describes the issues of callback hell and gives simple examples on how to clean it up. Modern JavaScript has gotten very complicated lately because it's so flexible. Many people are developing interesting frameworks to solve niche problems; however, it feels like many of these solutions are overly complicated outside the niche. Yet, developers are adopting…

Maybe it's because I'm a C programmer and not familiar with js but I felt this article did a very poor job of describing "callback hell." I still don't have a clear idea of what it is.

The author shows some code with lots of nested if/else clauses and claims this is bad because it blocks; fair enough. Then they explain what callbacks are and that some people have trouble understanding the asynchronous nature.

Then they immediately go into an explanation called 'How do I fix callback hell?' and meanwhile I'm scrolling up to see if I've missed something.

Perhaps people unfamiliar with this particular problem are not the target of this article, but that doesn't really make sense to me.

Re: Callback Hell (2016)

#93
post #91

This is where syntactic sugar can be helpful. CoffeeScript can make the example a lot more readable by removing the unnecessary braketing when the last argument of a function is a callback (common case in node.js). The only thing that's still ugly is the .bind() applied to a function, which somewhat messes with the style. Other than that, this makes callbacks flow a lot more naturally when reading source code. (Of co…

Please don't perpetuate the else silliness of the (intentionally bad) first example there. Stick a return in front of the log calls, lose the else, and unindent all following.

Re: Callback Hell (2016)

#95
These techniques seem to help code cleanliness in the small without attacking the root issue. Names and error handling help, but modularization requires more care than is demonstrated. The new module example separates the boilerplate, yes, but it also hides document selectors that assume page structure. So it's not actually modular. It's not reusable and it's brittle for the one page it was written for (if you change the markup and don't remember to change the module, the page breaks). It needs a way to pass in the elements queried in callbacks.

Re: Callback Hell (2016)

#96
post #49

The 'asynchonous problem' in JS is twofold. It makes it more difficult to reason about the program, and is hell on readability, and readbility matters. Support, maintenance, etc. The lack of an ability to structure async ops in a simple way is the biggest drawback in the language. Callbacks of course have the drawbacks mentioned. Sure, you can separate the functions, smaller functions and that too is preferred, but s…

I used to think that promises were pretty bad, but then i started using async/await. Now I think of promises as async/await with a lot of extra cruft. I have a colleague who prefers promises because they force programmers to break logic into small functions.

Re: Callback Hell (2016)

#97
post #91

This is where syntactic sugar can be helpful. CoffeeScript can make the example a lot more readable by removing the unnecessary braketing when the last argument of a function is a callback (common case in node.js). The only thing that's still ugly is the .bind() applied to a function, which somewhat messes with the style. Other than that, this makes callbacks flow a lot more naturally when reading source code. (Of co…

Please don't perpetuate the else silliness of the (intentionally bad) first example there. Stick a return in front of the log calls, lose the else, and unindent all following.

Yes, that is of course preferable. There are much better error handling strategies than what the example gave.

I was only commenting on the readability aspect, all other things being equal.

Re: Callback Hell (2016)

#98
post #79

I think this is a fantastic article in many ways. It clearly describes the issues of callback hell and gives simple examples on how to clean it up. Modern JavaScript has gotten very complicated lately because it's so flexible. Many people are developing interesting frameworks to solve niche problems; however, it feels like many of these solutions are overly complicated outside the niche. Yet, developers are adopting…

Maybe it's because I'm a C programmer and not familiar with js but I felt this article did a very poor job of describing "callback hell." I still don't have a clear idea of what it is. The author shows some code with lots of nested if/else clauses and claims this is bad because it blocks; fair enough. Then they explain what callbacks are and that some people have trouble understanding the asynchronous nature. Then th…

I believe the primary issues are a mistaken belief that "every line of code that gets executed should be read from top to bottom in the same order" (an issue with any code that isn't modular) and the debugging issue of using anonymous functions defined inline.

Readability of code is very important. Inline callback definitions hurt this.

Re: Callback Hell (2016)

#99
post #6

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running and so on down the file. As you will learn, JavaScript is different. A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main fe…

Are there JS runtimes that are primarily synchronous? Certainly not any popular/widely used ones. Asynchrony is for all practical purposes a property of JS.

Re: Callback Hell (2016)

#100

Lot of blabbling for a simple concept: do not abuse nesting. It's the case with control statements, it's still the case with functions, and even more with async functions. Oh, and callbacks definitely exist in other languages, like C. What's the deal with this trend of setting up a whole website for a (basic) blog post?

Don't be hatin'. It's a useful read for many. "Simple concept" is subjective. I'd bet that discussing "simple concepts" with an engineer or scientist would likely cause your mind to grasp and instinctively try to relate to your own memorization of facts. But that shouldn't preclude you from discussing what you do know, or for that matter, sharing it with the world.

(answering you, but also for otherz saying the same thing below)

Yeah you're probably right, I've been a bit pedantic.

I feel this article is unnecessary long for the subject, it would be a good length for something like "setting up a hadoop cluster", but having all sorts of articles about all subjects is a very good thing. My bad.

Post reply on HN