1

Every single example I read about it has code demonstrations that are synchronously executed, with the article writers pretending they're asynchronous.

No example I've seen yet says the code keeps running past the 'asynchronous' promise. If the code kept running while the promise was fulfilled, or the await was taking place, then it could be called asynchonous.

But if the main line of code stops for the promise/await response, then it's simply synchronous.

Can anyone explain this? I had the impression that code ran past the promise/sync function, rather than stopping and 'awaiting' the result to then continue the rest of the code identically to a normal synchronous execution operation.

VLAZ
  • 26,331
  • 9
  • 49
  • 67
SamusRk
  • 21
  • 1
  • This answer also has some details on promises and the JS event loop: https://stackoverflow.com/a/46375948/11308378 – Emma Feb 09 '22 at 18:06
  • Slightly, but it's too vague. My question is posed as a direct accusation against javascript promise/async functionality. There are no distractions with code examples and side issues. Also, the idea of code running past the function wasn't present or suggested by that. That is on the right path it's just posed weakly. – SamusRk Feb 09 '22 at 18:07
  • "*But if the main line of code stops for the promise/await response*" it does not. "*then it's simply synchronous*" therefore, it is not. – VLAZ Feb 09 '22 at 22:35

2 Answers2

1

Promises register callbacks for further execution when they resolve:

console.log('Beginning');
const test = new Promise(resolve => setTimeout(resolve, 1000));
test.then(() => console.log('Resolved'));
console.log('End');

Now if you think this is synchronous code:

(async function() {
  console.log('Beginning');
  const test = new Promise(resolve => setTimeout(resolve, 1000));
  await test;
  console.log('Resolved');
  console.log('End');
})();

Well it's not, it's actually an equivalent of:

console.log('Beginning');
const test = new Promise(resolve => setTimeout(resolve, 1000));
test.then(() => {
  console.log('Resolved');
  console.log('End');
});

Conclusion: when you await a Promise you just use syntactic sugar. Really nice syntactic sugar that prevents callback hell:

enter image description here

The call stack unwinds and frees the event loop with async/await, just like it would with callbacks, making the event loop available for other code execution until the Promise resolves.

Guerric P
  • 30,447
  • 6
  • 48
  • 86
  • I do have an issue with what people call callbacks too. In most examples, they simply post examples equivalent to a second function executed within a first function. That's not what a callback really is. – SamusRk Feb 09 '22 at 18:26
  • Indeed it's not, a callback is actually a function which is being passed as a parameter to another function for later execution. By doing this you say "execute this and then call me back by executing this code" – Guerric P Feb 09 '22 at 18:27
  • @SamusRk that *is* what a callback is. Assuming the second function is passed in as an argument. – VLAZ Feb 09 '22 at 22:27
  • Well like I said there are introductory descriptions all over the place that do not show this and almost intentionally seem to obscure that. – SamusRk Feb 10 '22 at 04:32
1

Promises themselves aren't really asynchronous. They are a pattern to implement working with other things that themselves are asynchronous.

Just like a callback is just a function, we tend to call them 'callbacks' if they get triggered at a later point.

All a Promise really is for is encapsulating the status of an asynchronous operation and let people access the result.

Asterisk: Promises themselves are also a little asynchronous, because they guarantee that the function passed to then() always happens at least in the next tick if the result already arrived.

And await doesn't block the process, it literally pauses the function and lets other things run. Similar to yield, which is also not asynchronous by itself.

Evert
  • 93,428
  • 18
  • 118
  • 189