That’s a very common misconception. async is just a scheduling tool that runs at the end of event loop (microtask queue). It still runs on the main thread and you can still lock up your UI. You’d need Web Workers for actual multi-threading.
Yes I’m simplifying a LOT, but in the context of background web calls, that was what callbacks became so important for. XMLHttpRequest in IE 5 sparked the Ajax movement and adventures in nested callbacks.
Prior to that, the browser had window.setTimeout and its callback for delays and animation and such - but that’s it.
The main purpose of all this async callback stuff was originally, and arguably still is (in the browser), for allowing the ui event loop to run while network requests are made.
NodeJS didn’t come into the picture for almost 10 years or so.
Yeah, that’s a big simplification and I get it. But the async syntax itself syntax “sugar” for Promises. It’s not like C# or Java/Android where it will spawn a thread. If you take a JSON of 1000 rows and attach a promise/await to each of them, you won’t hit the next event loop until they all run to completion.
It’s a common misconception that asynchronous means “run in background”. It doesn’t. It means run at end of current call stack.
Prior to that, the browser had window.setTimeout and its callback for delays and animation and such - but that’s it.
And you STILL have to call setTimeout in your async executions or else you will stall your UI.
Again async is NOT background. It’s run later. async wraps Promise which wraps queueMicrotask.
That’s a very common misconception. async is just a scheduling tool that runs at the end of event loop (microtask queue). It still runs on the main thread and you can still lock up your UI. You’d need Web Workers for actual multi-threading.
It can lock up a UI doing cpu bound work. Making a web request, no. Preventing the ui thread from waiting on native IO is what async was created for.
Citation needed.
asyncjust a wrapper for Promises. IO isn’t related, just commonly used with it.https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-async-functions-abstract-operations-async-function-start
NodeJS’s IO and
fetchare just promises. (And NodeJS used to usecallback(err, response)before adding promises.).Yes I’m simplifying a LOT, but in the context of background web calls, that was what callbacks became so important for. XMLHttpRequest in IE 5 sparked the Ajax movement and adventures in nested callbacks.
Prior to that, the browser had window.setTimeout and its callback for delays and animation and such - but that’s it.
The main purpose of all this async callback stuff was originally, and arguably still is (in the browser), for allowing the ui event loop to run while network requests are made.
NodeJS didn’t come into the picture for almost 10 years or so.
Yeah, that’s a big simplification and I get it. But the
asyncsyntax itself syntax “sugar” for Promises. It’s not like C# or Java/Android where it will spawn a thread. If you take a JSON of 1000 rows and attach a promise/await to each of them, you won’t hit the next event loop until they all run to completion.It’s a common misconception that asynchronous means “run in background”. It doesn’t. It means run at end of current call stack.
And you STILL have to call
setTimeoutin yourasyncexecutions or else you will stall your UI.Again
asyncis NOT background. It’s run later.asyncwrapsPromisewhich wrapsqueueMicrotask.Here is a stack overflow that explains it more in detail.