It's interesting that JS is still trying to figure out ways to make callback-based asynchronicity less-painful while Go managed to skirt the issue altogether. Go is readable, asynchronous and parallelizable largely without callbacks of any kind. Of course Go has its own problems, but I think they're largely orthogonal to its async story (i.e., JS could adopt Go's async strategy without adopting Go's more controversial features).
Callback Hell (2016)
111–120 of 170 posts
Re: Callback Hell (2016)
#112It's interesting that JS is still trying to figure out ways to make callback-based asynchronicity less-painful while Go managed to skirt the issue altogether. Go is readable, asynchronous and parallelizable largely without callbacks of any kind. Of course Go has its own problems, but I think they're largely orthogonal to its async story (i.e., JS could adopt Go's async strategy without adopting Go's more controversia…
JS became a language it was never meant to be not because of its merits, but because it is the language of the web.
Go is the language it was always meant to be, and a significant part of that was handling async.
Once async/await comes along, JS will have a really nice solution, and to be honest, I think it's pretty impressive that JS, with the history of its development, has been able to acquire new technologies of this nature.
Re: Callback Hell (2016)
#113> 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…
> 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
actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and completed. If you don't design for that, you WILL have race conditions.
Moving to nodejs 2 years ago, and something that I am still mindful of, is that you will NEVER have race conditions, as the entire user code will execute in a single thread, with interrupts only occurring between callbacks.
I like it because it's very easy to construct high performance professional apps in NodeJs (most devs are not multithreading experts) but sometimes I miss the idea of leveraging tons of cores. But that's why we scale horizontally (more 1 or 2 proc servers, less 32proc servers).
Re: Callback Hell (2016)
#114> 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…
> 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 actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and compl…
I agree. Asynchronous programming is orders of magnitude easier to grasp than concurrency. Especially in low lock scenarios. Interlocked.Increment(yourPost) :P
Re: Callback Hell (2016)
#115Earlier quoted context omitted.
Let me guess... It is hard for you to read long lines or your monitor isn't big enough? You might call that an accessibility thing right? You get what I'm getting at. You traded one accessibility that is fairly easy to fix (at worse case you have line wrapping) for one that is almost impossible to fix (zooming and large font don't really help).
It's hard for me to read long lines. I don't think 4 spaces makes it easier to know in what scope I'm in when there are a lot of scopes. The amount of white space is a bit overwhelming to me. But you know, it's no big deal, just a matter of taste. Maybe 3 spaces is a better answer, which I guess we'll never know...
> Maybe 3 spaces is a better answer
Re: Callback Hell (2016)
#116Earlier quoted context omitted.
What does it have to do with static typing? Function pointers are perfectly valid types. Also, can't you just use a debugger?
Not really in a custom ASIC in an embedded environment.
then your problem isn't C callbacks, it's that your debugging tools are inadequate.
Re: Callback Hell (2016)
#117> 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…
> 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 actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and compl…
You can still have race conditions anywhere IO is concerned, just not at a thread level (because no threads).
Re: Callback Hell (2016)
#118This 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…
That is almost definitely more messy looking than the alternative.
Re: Callback Hell (2016)
#119Typescript and RXJS (with ts mappings) make CB hell much more enjoyable. There is a learning curve to RX, but it's worth it.
Re: Callback Hell (2016)
#120I 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…
> See the pyramid shape and all the }) at the end? Eek! This is affectionately known as callback hell.
In other words, "callback hell" is simply the state of having too many nested inline callbacks. It makes the code uglier and for some harder to read. That's why pulling callbacks out into their own functions (i.e., making them no longer inline) fixes callback hell.