Demystifying Async Programming in JavaScript
blog.usebutton.comAm I wrong in feeling that callback hell is a symptom of bad design? In what scenario are you making four server requests before you can do something on a webpage?
I like async/await more for it's brevity than utility.
"Callback hell" as it is described in this article is a symptom of not understanding how to flatten your code for readability. Deep nesting is a trap in every language, it's the programmers job to know how to write readable code.
The problem with callbacks isn't the indentation. It's that downstream dependent logic has to take place in the callback.
If you have two logical branches that share a downstream, now you have a fork with identical callbacks.
So reducing callback indentation comes at the expense of indirection. You're not changing the nesting at all. Usually just brooming stuff under the rug.
> Am I wrong in feeling that callback hell is a symptom of bad design?
I think so, yes. Chaining together four consecutive web service requests might be a bad smell, but there are lots of other reasons to use async calls - waiting on a timeout, a worker, using IndexedDB, waiting on a user event or an animation, etc, etc.
In general if something can be done asynchronously it probably should be, so depending on the domain I'd say a lack of callbacks can be suspicious.
On the client, you are more likely to have a single API request. But on the server, you could be doing any mix of async things in a chain of dependencies + conditional logic.
Callback hell isn't a symptom of bad design. It's what happens when you have a lot of async function calls. Flattening callback hell often just contributes to callback hell with indirection, making it even harder to follow.
But thankfully we have promises, now.
microservices. the struggle is real.
Overuse of microservices is definitely a valid case of bad design.
Sure but you can easily compose 4 services into a single representation and still have an appropriate amount of decoupling. Think of a dashboard.
graphql points toward this
You can, but the pertinent question is whether you should. Microservices help with scaling endpoints that become bottlenecks but introducing them before they become necessary suffers from many of the common problems associated with premature optimisation.
It's interesting I think having an understanding of the history of javascript concurrency is almost a prerequisite to using it correctly. I wonder how new people approaching the language for the first time find it.
I find two camps: 1. those who need to produce backwards-compatible code, avoiding or not thinking about new features 2. those who can/want to use new features
Camp 1 has the problem of continuously importing kitchen sinks instead of polyfills, which would allow getting into camp 2.
Camp 2 is essentially a luxury of time, thus rare. It already requires mental commitment, which may be scarce after a day of battling bugs for IE.
I think that as a beginner you can get far with async/await without truly understanding it. I also think that at some time the abstractions will leak and your head will spin madly.