Promises: asynchronous code

Hello there!

I have been trying to understand promises and their use. I have read many comments here saw a couple of videos and read explanations in other websites but there is one concept that I am having trouble understanding: asynchronous code. I have translated it to my language, searched for information on what asynchronous code means but I still don’t get it.
It could just be a language thing but google translator ain’t helping.

if anyone could provide with a couple practical examples of an asynchronous code and the opposite of that I would really appreciate it.
Thank you in advance!

on what part of the curriculum you are? The deeper you go in it, the more clear it becomes, as the topic occasionally appears.
Im still newbie in the field myself and recently i had to work with asynchronous data requests to a server for the D3 projects and maybe i can help you with what i gathered as a concept. Asynch code awaits a certain event in order to be executed. Such thing is requesting a data from a server. You can make an app which utilizes this data, to produce certain events, render some elements, but this can only happen when the data arrives. To better understand it, you need to see it in action, come to the point when you actually get to use it in your own projects.

Sorry I should have mentioned. total newbie, i am at the Handle a Rejected Promise with catch in the ES6

sometimes i come across a few things that haven’t been explained yet (like map, reduce, this etc) and i google it.
But the Asynchronous i still have a hard time understanding.

So from what you tell me and what I have been reading we do Promises that work like functions with this type of code and it is only executed when they have a certain data right? it’s like a promise to execute as soon as something happens?
Any chance you could tell me an example of what a synchronized code is? (I assume that is the opposite and it would be the loops, and the ifs etc)

is there any example you could show me like in a project?

I usually prefer not to move forward until i grasped at least a little of the concept (recursion took me a couple of days and even now i can only explain it when i see it) but if you believe that when i start the projects part I will get there then I will take your word for it and just move on for now.

So, a real-world example i often use to explain asynchronous code: dining out.

Suppose you stop in a restaurant with a few friends, and everybody orders a meal. It’s a busy night, the wait-staff are all busy, but yours takes your order and passes it to the kitchen.

That order to the kitchen? It represents a promise. It is a “thing to come,” and will either resolve when you get your meal or reject when they realize they’re out of swordfish.

But the person who took your order is not stopped while your order is prepared, the kitchen is the asynchronous aspect. - the wait-staff keep taking other orders and delivering ready ones. They are awaiting the Promises, but they are not stopped to await them.

In the same way, unless you explicitly await some asynchronous code (some promise), your code will continue along doing its synchronous thing.


The ES6 section comes a bit forward on many topics. Things you wont face for a while. Even now i occasionally come back to ES6 section to refresh my memory on its contents. Promises were actually such occasion. As you learned, they can be used for retrieving data from another server/source and handling that data. I just finished the Data Visualization D3 projects and they all involve using data from an url address. What i am trying to say is, dont stress too much on every piece of incomprehensible thing, leave that for when you encounter it in your work.
The map, reduce and other array methods will come up and be explained later in the curriculum, where you will have better chance to understand them. Even then you might not completely grasp them, but eventually they come again in later courses and with some practice they become clear.
The recursion practice is also not something you inevitably want to use. Its cool and all but i suppose it finds its use in more end-game programming, if i can call it that. I guess its just there for us to be aware such thing exist. Only once i recall applying it in a project of mine, when i unaware created such a function.
If im not mistaken, basically any regular code is synchronous. Whatever you write and it isnt specifically stated to be asynchronous is synchronous :stuck_out_tongue_winking_eye: , as it follows the normal flow of events.

I usually try to explain how promises work with an analogy using the DC hero The Flash. The Flash is a super hero who has super speed. This is a long explanation but I think its a fun and interesting way to get an idea of how asynchronous code works without really getting into any syntax.

JavaScript is like The Flash, in that its super crazy fast, but can only be in once place at a time (JavaScript is single threaded). This is important to keep in mind while reading through my analogy.

So imagine a scenario where you get to use The Flash for a day to help you do stuff. The Flash is super fast so he can complete a lot of tasks quickly. However, as I mentioned there is a limit, he can’t be in multiple places at one time, so he’s fast, but he needs to “jump” around while things are happening. To stay efficient, he makes use of promising to come back when its his turn to perform the task rather than waiting the whole time.

So lets imagine you tasked The Flash with the mundane chore of doing your laundry. He’s super fast and gets all your clothes into into the washing machine at the nearby laundromat nearly instantly. However, it will take a while for your clothes to be done. During this time The Flash is just waiting for your laundry to finish and bring back to you. Being the awesome super hero he is, he promises to return to get the laundry when the laundrymat manager calls him back when your laundry is done, and he runs back to you so he can do whatever tasks you have for him next.

Now imagine you also want The Flash to get you a sandwich at a nearby deli. There’s now a problem with this, as The Flash can’t be in two places at one time. Even though he is crazy fast he has already promised to get back and get your laundry when its done, and now he also has to run over to the deli to get your sandwich. Again he has to wait in line for his turn make the order, and then wait for the sandwich to be made. While these task are being handled, he promises the manager of the deli to call him back when its his turn to make your order, and he runs back to you so you can tell him to do other tasks.

Now imagine you can’t think of any tasks for The Flash in the few seconds it took him to start these 2 task, which are now pending as he has to wait for the laundromat to call back, and the person in line to call and tell him its his turn to make the order.

He stands there for a few minutes not doing anything as all these other tasks are asynchronous. He suddenly gets a call back that its his turn to make his order for your sandwhich and dashes off. He makes the order as you like it, and the people at the deli start making it. He then promises to come back when the manager of the deli tells him, by calling him back when the sandwhich is done.

So he runs back to you and waits again for any possible tasks you have. Again you can’t think of any. After some more time the deli people call him back, and he runs back to get the sandwich and brings it back to you so you can stuff your face ;D

While your being happy and eating, The Flash gets another call from the laundromat that your laundry is done, and he dashes over and returns them to you.

You thank The Flash for his help and tell him to take the rest of the day off. :smiley:

So to review The Flash does a few interesting things here.
He doesn’t wait for things to finish, IE he doesn’t wait in line for his turn, or wait for your laundry to be done, he only promises to come back when they call him back when the task is finished. This way he can continue to be available to you during these times, and can essentially perform multiple tasks at once.

JavaScript is the same, in that it can perform multiple slow tasks at once by relying on callbacks and promising to come back later when the callback is executed. So if your making a network call, which can take several seconds you can use a promise-callback to have JS come back when the data is available.

The other thing about The Flash, is that because he is so fast, he generally isn’t really “waiting” to do anything except receive more commands.

This is also true for JavaScript, which will continue to execute commands when they are made, but generally will complete them and be waiting for these asynchronous and slow tasks to be completed by other people/systems and call him back when they are done.

In both scenarios The Flash/JavaScript ends up “jumping around” to what requires his attention, and a key part of that is using promise-callbacks to let him know.

Finally its worth mentioning that an alternate approach is to just have a superhero who duplicates themselves and performs each task at normal speed, but is in multiple places at once. This is called multi-threaded programming, which other languages can use to perform multiple tasks, but JavaScript doesn’t really utilize this structure or approach, but its worth keeping in mind.


So its safe to say other languages behave like the X-men or Avengers ^^

Very enlightening explanation btw :slight_smile:

Thank you very much! My main concern was leaving something behind that I would absolutely need soon but knowing that this is revisited a little further a head i am a little more at ease.

Thank you once again for your explanation!

neat explanation! Thank you very much!

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.