Is async a good choice

[phppup]

I'm trying to understand async, I promise, but it seems like a slick fakeout.

[Of course, this has only come up after AI used it bc it couldn't/still hasn't fixed some code.]

Nonetheless, I'm wondering how popular and reasonable it actually is. I've done a fair amount of researching, and async seems to be a 'work-around' to avoid writing a few extra lines of code.

ie: save this value in a variable and give it to me last (almost like an overwritten value), no matter what.

Am I missing something.

PS: I've seen numerous examples that say the same thing, so I'm really looking for an honest human opinion.

[requinix]

"A work-around to avoid writing a few extra lines of code" ?

[requinix]

If you're used to having, say, the occasional asynchronous operation somewhere in a codebase: yes, async is saving you a few lines of code.

But for anything more than the most trivial amount of callback hell, async is a much, much cleaner solution.

[gizmola]

12 hours ago, phppup said:

I'm trying to understand async, I promise, but it seems like a slick fakeout.

Am I missing something.

PS: I've seen numerous examples that say the same thing, so I'm really looking for an honest human opinion.

Javascript allows for asynchronous functions. 

To understand how JS works in the browser there are some educational resources like this one, that help illustrate things that aren't easily understood just by looking at js code.  While a highly watched video when released, if you do watch it, just keep in mind that it was created prior to ES6 was fully released and supported by the major browser engines.

There are now a few visualizers like this one:  https://www.jsv9000.app/ you can use to step through code.  

The Javascript engine allows for asynchronous functions through its implementation of a "Task Queue".  

Prior to ES6, asynchronous calls required callback functions.  The use of many nested/interwoven asynchronous functions with various callback functions can be highly confusing, and for people used to procedural programming, it lead to confusion and a proliferation of functions often referred to as "callback" hell.

• Promises were introduced with ES6 as a way of organizing Async calls. "A Promise is an object representing the eventual completion or failure of an asynchronous operation."
• Along with support for promises, the javascript engines added a 2nd queue: the MicroTask queue.
• In particular, Promises were created to better support chaining asynchronous functions together, as in many situations, you want a series of functions to run, any of which can return out of order, and still be able to chain those results together in the order required.  This comes up frequently when using external API's where there are a number of different calls being made within any specific area of code.
• I would just be regurgitating what is on this page to elaborate much further:  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises

For some people, the look of a series of chained Promises, each of which returns additional promise objects looks less procedural than they would like, particularly when there are chained async calls that need to be resolved in order.  For that reason, ES7 included the async and await keywords and syntax.  

It's your choice as to whether you want to use async/await or just stick with promises, although there are some things that promises can do that are not as easily done (or perhaps done at all) just using async/await syntax.  

Again, I would defer to the explanation on MDN, and that page in general for more explanation and examples, as it begins with:
 

Quote

 

The async function declaration creates a binding of a new async function to a given name. The await keyword is permitted within the function body, enabling asynchronous, promise-based behavior to be written in a cleaner style and avoiding the need to explicitly configure promise chains.

You can also define async functions using the async function expression.