Understanding Synchronous and Asynchronous JavaScript - paRt_1 : JavaScript - its DiFFereNt

In JavaScript Synchronous and Asynchronous are very important concepts. Beginners might find them difficult to learn.

When two or more things happen at same time then it is Synchronous and when they don't that's Asynchronous. These definitions are easy to understand but it's complicated than it looks from here. So let's dig a little deeper. 
You’d probably call a normal function in JavaScript synchronous, right? And if it’s something like setTimeout() or AJAX that you’re working with, you will refer to it as being asynchronous, yes? What if I tell you that both are asynchronous in a way?
Let's understand with an example. We'll get help from Mr. K,

Scenario 1:-> Mr. K is trying Synchronicity 

Here’s the setup:

1. Mr K is someone who can answer tough questions, and carry out any requested task.
2. The only way to contact him is through a phone call.
3. Whatever question or task you got, in order to ask Mr K’s help to carry it out; you call him.
4. Mr K gives you the answer or completes the task right away, and lets you know it’s done.
5. You put down the receiver feeling content and go out on a date.

What you’ve just carried out was a synchronous (back and forth) communication with Mr K. He listened as you were asking him your question, and you listened when he was answering it.

Scenario 2:-> Mr. K isn't happy with Synchronicity 

Since Mr K is so efficient, he starts receiving many more calls. So what happens when you call him but he’s already busy talking to someone else? You won’t be able to ask him your question – not till he is free to receive your call. All you will hear is a busy tone.

So what can Mr K do to combat this?

Instead of taking calls directly:

1. Mr K hires a new guy, Mr J and gives him an answering machine for the callers to leave messages.
2. Mr J’s job is to pass on a message from the answering machine to Mr K once he knows Mr K has completely finished processing all previous messages and is already free to take a new one.
3. So now when you call him, instead of getting a busy tone, you get to leave a message for Mr K, then wait for him to call you back (no date time yet).
4. Once Mr K is done with all the queued up messages he received before yours, he will look into your issue, and call you back to give you an answer.

Now here lies the question: were the actions so far synchronous or asynchronous?

It’s mixed. When you left your message, Mr K wasn’t listening in to it, so the forth communication was asynchronous.

But, when he replied, you were there listening, which makes the return communication synchronous.

Until now you must have understand synchronicity in communication. It's time to bring in JavaScript in the picture.

JavaScript An Asynchronous Language

When someone labels JavaScript asynchronous, what they are referring to in general is how you can leave a message for it, and not have your call blocked with a busy tone.
The function calls are never direct in JavaScript, they’re usually done via messages. 
JavaScript uses a message queue where incoming messages (or events) are held. An event-loop (a message dispatcher) sequentially dispatches those messages to a call stack where the corresponding functions of the messages are stacked as frames (function arguments & variables) for execution.
The call stack holds the frame of the initial function being called, and any other frames for functions called via nested calls on top of it .

JavaScript Call Stack

When a message joins the queue, it waits until the call stack is empty of all frames from the previous message, and when it is, the event-loop de-queues the previous message, and adds the corresponding frames of the current message to the call stack.
The message waits again until the call stack becomes empty of its own corresponding frames (i.e. the executions of all the stacked functions are over), then is de-queued.
Consider the following code:

function foo(){}
function bar(){
  foo();
}
function baz(){
  bar();
}
baz();

The function being run is baz() (at the last row of the code snippet), for which a message is added to the queue, and when the event-loop picks it up, the call stack starts stacking frames for baz(), bar(), and foo() at the relevant points of execution.

Push action in Call Stack

Once the execution of the functions is complete one by one, their frames are removed from the call stack, while the message is still waiting in the queue, until baz() is popped from the stack.

Pop Action in Call Stack

Remember, the function calls are never direct in JavaScript, they’re done via messages. So whenever you hear someone say that JavaScript itself is an asynchronous programming language, assume that they are talking about its built-in “answering machine”, and how you’re free to leave messages.

But what about the specific asynchronous methods?

So far I’ve not touched on APIs such as setTimeout() and AJAX, those are the ones that are specifically referred to as asynchronous. Why is that?
It’s important to understand what exactly is being synchronous or asynchronous. JavaScript, with the help of events and the event-loop, may practice asynchronous processing of messages, but that doesn’t mean everything in JavaScript is asynchronous.
Remember, I told you the message didn’t leave until the call stack was empty of its corresponding frames, just like you didn’t leave on a date until you got your answer — that’s being synchronous, you are there waiting until the task is complete, and you get the answer.
Waiting isn’t ideal in all scenarios. What if after leaving a message, instead of waiting, you can leave on the date? What if a function can retire (emptying the call stack), and its message can be de-queued even before the task of the function is complete? What if you can have code executed asynchronously?
This is where APIs such as setTimeout() and AJAX come into the picture, and what they do is… hold on, I can’t explain this without going back to Mr K, which we’ll see in the second part of this article. Stay tuned...