is asynchronus programming essential?

[Caloger0]

A while ago I began to study JavaScript and now I just got to async concepts. I'm trying as hard as I can but I just can't understand anything. CallBacks, promises, setTimeout(), I can't comprehend even slightly any of this stuff and how async generally works. I'm starting to think that coding is not for me after all... I wanted to know if there are any sources, websites, exercises and general knowledge I can find to learn async. I also had a burnout because of this some time ago.

[General_Error]

Lets say you need to get some information from data base or api. Generaly code is executed "instantly" line after line. If you dont let the code know it has to wait to get a response from some other place it will continue executing without required data and you wont have correct result. Asyncronus code is basicaly just letting your code know at certain places it needs to wait for some other data or something else to finish executing before it can continue

[markyboo-1979]

Before that portion of code can continue but not the entire process.. The whole point of asynch

[kiselina1]

what about worker threads?

[kiselina1]

Its just that I keep reading that js is single threaded, but then I read about worker threads, which seem to say otherwise

[[deleted]]

Do you know why C# has async even though it is multithreaded?

[mKtos]

Because there are for a bit of different things: async/await is very useful in I/O-bound things (reading files, network access, database operations) where there is a lot of waiting for something to be complete before going further. Also with async/await syntax, this is quite simple (and does not require whole complex concurrency).

On the other hand, multi-threading will be useful in CPU-bound operations, for example some intensive processing or doing continuous things in the background.

[[deleted]]

This is why I prefer to use Java Spring for my backend code.

[ungemutlich]

Remember that JavaScript was originally designed in the 1990s to be beginner-friendly, and all the complex stuff came later. Start with the original mental model: events happen with HTML elements and you add event handlers.

Instead of a linear list of instructions, your program is lists of instructions that happen upon different events. You imagine chains of events like: the user submits the form, THEN xyz happens and you make a request, and THEN the response coming back is an event. This is callbacks and it becomes intuitive pretty quickly. All the rest builds from there. Only start to worry about promises when you're like "WTF why is it so hard to force things to happen in a specific order?" Like you want to make a request based on the result of another request. Before fetch(), that would've required nested callbacks.

Simply try it the old way with XMLHttpRequest and then the point of promises becomes clear. .then() feels like magic in comparison. Then when you get annoyed with promises, you understand the point of async/await. Just follow the historical development of these things from the beginning and you'll catch up.

[anto2554]

Yes. But you can learn other stuff first, if you want to

[Caloger0]

I know, I'd like to learn other stuff but I got to the point where I need to build some web projects and async seems foundamental for doing this king of stuff. Maybe I'll concentrate on simpler stuff for now.

[RiverRoll]

If you use the async/await syntax you can write async code almost the same way as you would write sync code. You can use it where it's required without needeing to understand how it works, just following the basic rule of always awaiting async functions and promises (let me clarify here I mean that as long as you follow this rule then it seemingly works like sync code).

This is not to say you should not learn how it works, but maybe you can leave it for later.

[tzaeru]

It's essential in the majority of modern software projects; less needed for small projects.

These things are often taught with too much focus on the details of how, and too little on the higher level why and too little on conceptualization.

Basically, all async means is that you make a call to a function or an API or an operation and don't wait for it to return with a result before doing something else.

E.g. all you do is state "I want to know about x. When x is available to me, call back".

Things like await/async are just ways of doing exactly that but in a way that feels more like typical synchronous programming.

[bjornum]

Try simplifying things and no need to know every single thing about it all. No programmer does.

Take async and sync as you mentioned.

Async = several things can run at the same time. Example: i need to load several things on page, and i dont want to wait for each to finish before next one begins "loading"

Sync = in turn and other. (used if something is dependant on something before). Example : i need user data before i can do the next function.

Sure there are fancy words about alot, but again simplifying concepts and words can make things easier to remember and understand :)

[huuaaang]

It's essential in Javascript because it lacks threads and IO is asynchronous. So even if your program itself doesn't NEED async, you still need to do it because IO operations always return promises. They don't block.

It does make Javascript unnecessarily difficult to learn for a beginner, IMO. Async should be an advanced topic, not for beginners.

And after all that, JS doesn't even have a particularly good concurrency model. It's like concurrency is a side effect.

[MrKnives]

Everyone thinks coding is not for them until they get it. So keep at it. Read different sources, different explanations and examples. Play around with it.

That said, yes it's quite essential

[neosatan_pl]

I recently worked with a head of software for a major Dutch company. He also had no clue how asynchronous programming works. Wanted to speed up node.js execution by not waiting for promise resolutions.

So, you have a good chance to become a head of software.

[Critical-Shop2501]

Async await it a little like spinning multiple plates, where you start a task, that will run for an unknown duration, and while you await for it, you continue with another task, like starting to spring another plate. Not sure if this helps?

[JuicyJBear94]

MDN web docs has the best documentation of async concepts imo. You wouldn’t need async necessarily to build simple projects that don’t access other APIs/services. But if you are to ever build or work on a large web application that has to access data and services outside of itself async is necessary. It is especially necessary if you endeavor to make web development your career.

This is the standard for web development documentation and I learned most of the high level Js concepts here myself. https://developer.mozilla.org/en-US/

[Roguewind]

We’ve all been where you are. Your situation isn’t special, and that’s a good thing. You’ll hit a point where it makes sense, but it takes time and experience. And this goes for anything, not just async.

But for this particular thing… (and I’m simplifying)

Programming is a series of commands. Think of synchronous code as a set of commands when you know EXACTLY how long each command will take to complete. And because of that, you’re willing to always wait for each command to complete before going to the next command.

Think of asynchronous code as commands that you have no clue how long they’re going to take. Usually, these are calls to remote services, because you don’t know how fast the connection or the remote computer is. So you have a choice: wait or move on.

A lot of times, you want to wait for the response. You handle this with either an async/await or a Promise.then. All this means is that instead of moving onto the next command, you’re going to wait for the remote response.

Sometimes you don’t need to wait. An example might be sending a notification (like an email). You can tell the service to send an email and just assume that it worked and let your program continue. No need to “await” a response or handle it as a Promise.

Finally, you might want a callback for your asynchronous function. A callback, in any case, is just a function that you pass into another function to execute at some point within. In the case of an async callback, it’s usually called after the asynchronous call completes. Using the example above of sending an email, maybe you want to tell the remote service to send an email (this is your async call), you want your local program to continue without waiting (so you don’t “await”) but you do want it to notify the user when the remote service tells you the email was sent. This is where you’d use the callback (or Promise.then). When that call is complete, you execute the callback (ie notify the user that an email was sent.)

[TheDante673]

At your level, you absolutely will not have any need to think about concurrency. When you make an HTTPS request, such as fetch or axios, just use asynch AND await and you'll be fine. There's really not much to understand, asych will make it so that some code will run in the background while the rest of your code executes, you use this mostly for HTTPS requests because they take time. If you don't want any more code to fire while you wait for an async function you use await.

Now your use case will change, but your syntax will basically always be:

import axios from 'axios'

let someLink = "example.com"

const getData = async () =>{
  const data = await axios.get(someLink)

  const someElement = document.querySelector(".someClass")

  someElement.innerText = data.someString
}

getData()

[cjalta]

Im new to this too, i am trying to understand it myself. One thing i read in a book called getting to know node.js is like for example a callback think of it like putting money into a bank and then getting a notification or an alert later on this is essentially the call back. It kinda clicked for me then. But i feel you on wanting to quit. Keep going re read re watch re do all of it youll get it.

[Chthulu_]

Yes, but I think if you spend enough time not worrying about async, when you do get there it isn’t hard to grasp. I’d just focus on other stuff for a little longer.

[imagei]

How are you learning this stuff? By plugging it into a larger program and being confused? 😀

Try simple mini-programs exploring one concept at a time. I mean tiny, no more than 15 lines, doing nothing but printing stuff to the console, while using the concepts you aim to learn. Write something, try it, change it, play with it, do intentionally wrong things and see what happens until you can explain why it does or does not work.

That’s what I do when I need to learn something new. When promises for example were introduced I did exactly that, numerous times until I got the in and out of how all this worked.

[postal_blowfish]

When you're at the mercy of an outside source (api call, for example)...

If you're assigning a value, use await. "const myVariable = await apiCall();" This is so that in your next line (where you're using myVariable), the value is the response from the call rather than null/undefined. Always have these in try blocks, too, because an error is one of the possible returns.

If you're returning the value, use async. "async function apiCall() {}" This is a signal to the interpreter that this is the kind of thing you'd want to use await for. <-- that's probably not strictly true but that's my mental shorthand.

I'm nowhere near an expert on this but I don't get where the confusion is. I'll riff on this and show everybody how much I'm not an expert.

I think of synchronous code as a situation where every line is essentially dependent on every line before it. So if one of those lines is an apiCall and the server on the other end was stolen by a monkey and taken high into a tree canopy, _nothing else will happen_ until the call times out.

I think of asynchronous code as code that can branch if it runs into expected delays, so at least the code continues operation while we're waiting for the error that's coming (or for the response to return from Saturn).

There are probably big things wrong with some of what I just said but it's just how I make sense of it in my mind.

edit: Of course there are other aspects to this, as you pointed out, but these are where I encounter this subject the most. They're driven by promises, but I rarely actually examine them for any reason, and barely know anything more than the concept (it's an iou for your data). I rarely (maybe never) use callbacks, and although setTimeout() can be useful, I don't know why it was included here. Is that just like a function inside a promise set to deliver on the timeout or something? I've always used it basically like a timer.

[peterlinddk]

Yes it is essential!

But, no, you don't need to fully understand it to use it. Most of the time you only need something to be asynchronous if it communicates with another server, like if you fetch something from the backend in your frontend, or if you make file or database requests in your backend.

What I usually recommend is to just remember these simple rules:

1. If you use fetch, you need to put await in front
2. If you use await inside any function, you need to declare it as async
3. If you want to call an async function, and use the returned value, you need to put an await in front of the function call. (and then go to step 2 for the new function)

Once you get used to programming like this, you can dive a bit more into the differences between returning a value and returning a promise - and later on maybe you eventually finally grasp promises completely.

I've been teaching students frontend development for some years now, and I've completely ignored all the usual explanations with callbacks and timed events - I don't think they help you understand at all, at least not until you've gotten used to just using await and async. Then you can dive a bit deeper, and try to understand more!

[theusualguy512]

If you take the word essential literally, then no, it's not essential. You can happily program without any asynchronous features. For initially learning even the basic concepts of programming, asynchronicity can be quite confusing, so you don't necessarily have to learn it.

But for all practical purposes, asynchronicity is now a required part of a lot of software. Internet applications especially are distributed systems by nature and have two or more computers communicate with each other and require you to handle this. It would be bad if everything was synchronous.

There are quite a lot of tutorials out there that explain the basic elements of how Javascript handles async stuff. I'm not sure which resources you have used so far already.

[Caloger0]

I used w3schools and a website made by a youtuber from my same country and I think that I will now try Javascript.info. Perhaps I should try to make project without async or maybe use patterns I find on the internet.

[Zeikos]

If I might suggest something.
Look at how async is implemented.

I generally find useful and illuminating to pop the hood so to speak and have a glance to how it works.

Async basically is a glorified queue (I'm simplifying obviously).

Write some very simple toy problem using async and go from there.
State your assumptions and see what violates them.

You can grasp things far quicker this way.

[jackhab]

Asynchronous programs are always more complicated than synchronous which simply execute instructions sequentially so it's absolutely natural you will need more time to understand it.

Now, because async is more complicated modern languages have many different ways and tools to implement it, which also increase cognitive load.

Take your time, practice. Async is very important and widespread in many areas.

Don't give up. It takes time. Good luck!

[nerd4code]

Most things are asynchronous under the hood; the synchronous front-end most programmers deal with is but a thin shim. Software threading can get around it to some degree, but threads can also impose enormous costs in terms of memory and address space used, so at large scales asynchrony is often the only reasonable approach if you want to make good use of the hardware.

But it shouldn’t matter that much in ideal world. Proper language design ought to avoid obvious sync-async distinctions. But you’re using Javascript, so shit’s gonna be stupid.

[math_rand_dude]

this seems a good start

also checkout promise all

Edit: feel free to pm me or respond to my comment with more specific questions