I honestly don’t know, why async got so popular. It seems like the entire reason for doing it was that some blokes were hellbent on using JS on a server and couldn’t fathom that a second thread might be a good idea.
If you need to get multiple pieces of data for one request Async is great, but why would you work on different requests in the same thread? Why slow down one request because the other needs a bunch of computation?
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.
You suck, I hate how your comment was forced “apon” me. Anyone who claims things that they can easily avoid if theyre so opinionated against them are “forced upon” them are always pathetic people.
async/await is just callback() and queueMicrotask wrapped up into a neat package. It’s not supposed to replace multi-threading and confusing it for such is dangerous since you can still stall your main/UI thread with Promises (which async also wraps).
(async and await are also technically different things, but for the sake of simplicity here, consider them a pair.)
After using both extensively I would argue async code is easier to read. It has a lot less nesting. And generally easier to read code is a good thing so I’m all for async.
Nah, they’re very similar, really. You generally kick IO heavy stuff you don’t need immediately off to async await.
There are a few more applications of it in C# since you don’t have the “single thread” to work with like in JS. And the actual implementation under the hood is different, sure. But conceptually they’re similar. Pretty sure JS was heavily influenced by C#'s implementation and syntax.
Async is good because threads are expensive, might aswell do something else when you need to wait for something anyways.
But only having async and no other thread when you need some computation is obviously awful… (or when starting anothe rthread is not easily manageable)
Thats why i like go, you just tell it you want to run something in parallel and he will manage the rest… computational work, shift current work to new thread… just waiting for IO, async.
I honestly don’t know, why async got so popular. It seems like the entire reason for doing it was that some blokes were hellbent on using JS on a server and couldn’t fathom that a second thread might be a good idea.
A huge amount of time in apps is spent waiting for IO, database or web requests to complete.
Async prevents locking a thread during this wait.
If you’re handling a large amount of requests in a web server, for example, it allows other requests to progress while waiting for these operations.
Threads are also expensive to start and manage.
Also handling threads manually is a pain in the ass.
If you need to get multiple pieces of data for one request Async is great, but why would you work on different requests in the same thread? Why slow down one request because the other needs a bunch of computation?
You aren’t slowing down anything. If you didn’t use async that thread would be blocked.
You’d need a thread per request even though they are sat doing nothing while waiting for responses.
Instead when you hit an await that thread is freed for other work and when the wait is over the rest of the code is scheduled to run.
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.
Async rust with the Tokio Framework is pretty cool. Need none of that JS bloat for async.
Async Rust sucks. I hate how many libraries use it, forcing it apon you.
You suck, I hate how your comment was forced “apon” me. Anyone who claims things that they can easily avoid if theyre so opinionated against them are “forced upon” them are always pathetic people.
Because the alternative is a series of ridiculously nested call backs that make code hard to read and manage?
I honestly can’t fathom how anyone would dislike async programming.
If you are waiting for IO, why would you block your current thread and not let it do something else? Async does not only exist in JS.
async/await is just
callback()andqueueMicrotaskwrapped up into a neat package. It’s not supposed to replace multi-threading and confusing it for such is dangerous since you can still stall your main/UI thread with Promises (which async also wraps).(
asyncandawaitare also technically different things, but for the sake of simplicity here, consider them a pair.)After using both extensively I would argue async code is easier to read. It has a lot less nesting. And generally easier to read code is a good thing so I’m all for async.
Ok, I’m a c# developer and I use async await quite extensively. Is it different in JS? Or am I missing something?
Nah, they’re very similar, really. You generally kick IO heavy stuff you don’t need immediately off to async await.
There are a few more applications of it in C# since you don’t have the “single thread” to work with like in JS. And the actual implementation under the hood is different, sure. But conceptually they’re similar. Pretty sure JS was heavily influenced by C#'s implementation and syntax.
Async is good because threads are expensive, might aswell do something else when you need to wait for something anyways.
But only having async and no other thread when you need some computation is obviously awful… (or when starting anothe rthread is not easily manageable)
Thats why i like go, you just tell it you want to run something in parallel and he will manage the rest… computational work, shift current work to new thread… just waiting for IO, async.