Demystifying Async Programming in JavaScript
blog.usebutton.com
Demystifying Async Programming in JavaScript
1–10 of 13 posts
Re: Demystifying Async Programming in JavaScript
#2It'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.
Re: Demystifying Async Programming in JavaScript
#3It'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.
Re: Demystifying Async Programming in JavaScript
#4Am 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.
Re: Demystifying Async Programming in JavaScript
#5Am 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.
microservices. the struggle is real.
Re: Demystifying Async Programming in JavaScript
#6Am 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.
microservices. the struggle is real.
Overuse of microservices is definitely a valid case of bad design.
Re: Demystifying Async Programming in JavaScript
#7Earlier quoted context omitted.
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
Re: Demystifying Async Programming in JavaScript
#8Am 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.
Re: Demystifying Async Programming in JavaScript
#9It'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 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.
Re: Demystifying Async Programming in JavaScript
#10Earlier quoted context omitted.
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 https://github.com/facebook/graphql
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.