We Keep Coding

Can someone explain JS Event Loop?

So I kind of understand the JS event loop, but still have a few questions. Here is my scenario and a few questions.
So let's say I have these functions:
function1 - reads an absolute huge file.
function2 - console.log("Hey");
function3 - console.log("What's up");
The way I am understanding this, and correct me if I'm wrong, what would happen is that the function1, function2, and function3, would be added to the queue. Then function1 would be added to the call stack followed by the next two functions.
Now the part where I'm confused is because the first function is going to take an extremely long time what happens to it? Does it get pushed somewhere else so that the next two functions are executed? I think the answer to this is that the only way it gets pushed somewhere else so that you can continue running is to make it an asynchronous function. And the way you make it a asynchronous function is either by using a callback function or promises. If this is the case how does it know that this is a asynchronous function? And where does it get pushed to so that the other two functions can be executed since they are relatively simple?
I think I answered the question myself but I keep confusing myself so if somebody could explain in extremely simple terms that would be great and sorry for the extremely stupid question.

Ordinary function calls are not pushed on the event queue, they're just executed synchronously.
Certain built-in functions initiate asynchronous operations. For instance, setTimeout() creates a timer that will execute the function asynchronously at a future time. fetch() starts an AJAX request, and returns a promise that will resolve when the response is received. addEventListener() creates a listener that will call the function when the specified event occurs on an element.
In all these cases, what effectively happens is that the callback function is added to the event queue when the corresponding condition is reached.
When one of these functions is called, it runs to completion. When the function returns, the event loop pulls the next item off the event queue and runs its callback, and so on.
If the event queue is empty, the event loop just idles until something is added. So when you're just starting at a simple web page, nothing may happen until you click on something that has an event listener, then its listener function will run.
In interactive applications like web pages, we try to avoid writing functions that take a long time to run to completion, because it blocks the user interface (other asynchronous actions can't interrupt it). So if you're going to read a large file, you use an API that reads it incrementally, calling an event listener for each block. That will allow other functions to run between processing of each block.
There's nothing specific that identifies asynchronous functions, it's just part of the definition of each function. You can't say that any function that has a callback argument is asynchronous, because functions like Array.forEach() are synchronous. And promises don't make something asychronous -- you can create a promise that resolves synchronously, although there's not usually a point to it (but you might do this as a stub when the caller expects a promise in the general case). The keyword async before a function definition just wraps its return value in a promise, it doesn't actually make it run asynchronously.

Clarification on synchronous and asynchronous callbacks in javascript

iam currently working through the concept of callbacks and asynchronous programming in javascript. For that i read the corresponding chapters in the book "JavaScript" written by Philip Ackermann (ISBN:937-3-8362-5696-4).
But i have problems understanding the term asynchronous applied to callbacks used in examples of the book.
My current understand is that i can write synchronous callbacks like this:
function synchronousCallback(text, callback) {
//other code
callback(text);
}
synchronousCallback("End of function", console.log);
In the above example the callback is in my opinion only a nested function call. Nothing more.
But in a similar example of the book the author calls such a function asynchronous. See below the exact example of the book:
function asyncFunction(callbackFunction) {
//some code
console.log('Before callback');
callbackFunction();
console.log('After callback');
//some more code
}
function callbackFunction() {
console.log('called callback');
}
asyncFunction(callbackFunction);
My understanding of the code execution is that this callback would be executed as soon as the 'other code' is finished. The callback would not be added to the callback queue of the javascript engine and therefore be synchronous/blocking.
In my point of view a callback is asynchronous when used with setTimeout() or setInterval().
Maybe the example in the book is misleading or i misunderstood the term asynchronous in that case or i didnt not understand the execution order of such a callback scenario correctly.
Thanks for any help or clarification

There's nothing asynchronous about the example you gave.
Callbacks are asynchronous if the JavaScript event loop carries on running the rest of your program until an external factor (time passing in the case of setTimeout) triggers the callback.
Either the book is wrong, or you've not adequately expressed everything in the "similar" example it gave.

I have already mentioned the difference between synchronous and asynchronous behavior in JavaScript with this answer to your other question. I'll try to give you more details with this answer.
There, I recommended that you watch couple of talks about the subject. A talk by Philip Roberts, another talk by Jake Archibald or Jake's blog which explains the same. I'll try to summarize all of that.
All JavaScript code is synchronous and executes within a single thread. This means that there's one call stack and it can do one thing at a time. To better understand JavaScript runtime, please take a look at this image taken from MDN.
Let's try to go through your second example to see what's going on. When asyncFunction() gets called, it is pushed to stack (Jake calls them tasks, but based on MDN image, they are frames). Then, console.log('Before callback') is called and it gets pushed to stack on top of the current frame. So now, there's console.log on top and asyncFunction below.
console.log logs that string to console. Then, it's removed (popped) of the stack. asyncFunction is now on top of the stack. Now, callbackFunction() gets called and it is pushed to the stack, which then calls console.log('called callback') which also gets pushed to the stack.
Now, there are three functions on the stack: asyncFunction at the bottom, callbackFunction and console.log at top. When console.log finishes its job, it gets popped off the stack and now callbackFunction is also finished and that one also gets popped off the stack. Now, console.log('After callback') is called, pushed to the stack and popped after execution, which means that asyncFunction is finished and can be popped off the stack.
This is where all ends, the stack is empty, no more frames on it. Based on this and talks from the link above, there's nothing asynchronous in this example. A step by step is made by JS runtime and no asynchronous jumps are made here. But, how do we achieve concurrency in JS and do we need it? To quote Philip:
The reason we can do things concurrently is that the browser is more than just the runtime.
This is the reason why we can use setTimeout(() => { doSomething(); }, 5000) which would wait for 5(000 thousand milli)seconds without blocking (freezing) web page during that time. What happens when setTimeout is called? The browser starts another thread which runs in parallel. The thread's job is to only wait for 5 seconds. But, now it gets interesting what happens when the time's up.
To prevent concurrent modifications which might lead to unexpected behaviors, browsers have a queue mechanism. This allows the thread created by setTimeout to post a message to it and the message is, in this case, a function passed to setTimeout that will get executed once the message is processed.
But when are the messages processed? Well, just after no frames (tasks) are stacked. This means that messages are waiting for stack to get cleared after all frames are finished so that they can be processed. Messages are processed one at a time per one loop. Once message is taken as task it becomes regular JS code which gets executed on the same thread with the same rules for pushing and popping stack. Any other potential messages that are queued in the meantime must wait for the current message/frame to be processed.
setTimeout and setInterval are all parts of WebAPIs. Many (if not all) of them have asynchronous callbacks, and some examples include: DOM events, XHR events, Fetch events, Web workers, Web sockets, Promises, MutationObserver callbacks and so on. The last two (Promises and MutationObservers) schedule tasks on a different queue (microtask queue), but it's still asynchronous.
The difference between messages that are set to microtask queue and regular (or macrotask) queue is that the messages from macrotask queues are taken one at a time per event loop (which means that the whole loop needs to go around between two messages are processed), while messages from microtask queues are taken immediately after the stack is cleared. This means that they have higher priority than the ones on the macrotask queues. For more info, please watch/read Jake's talk/blog.
In my point of view a callback is asynchronous when used with setTimeout() or setInterval().
Yes, but not only with setTimeout() or setInterval(). If you set your callback to XMLHttpRequest's onreadystatechange function, it will be called asynchronously all the same.
Please note that there may be other APIs that require different set of function parameters than the ones from these examples - in fact, these examples aren't using function parameters at all.

Javascript sync and async processes priority

I was researching about javascript's async behaviour despite being single-threaded and I came after a comment stating that for this code:
request(..., function (error, response, body)
console.log('foo);
});
callAComputationallyIntensiveSynchronousFunctionThatTakesSixHoursToExecute();
console.log('bar');
'bar' will still come before 'foo' because Javascript always finishes the currently executing function first. An event will never interrupt a function.
I understand that a synchronous function execution has a higher priority over events, but I don't understand why 'bar' will be printed before 'foo'. From my reading, the async call should be made, and after that to fill the dead time before response is ready, it goes on and processes the other lines of code until it is ready, and then it should execute the callback function for the response and after that return to processing the code and so on.
The example above however states that even if the response would be ready long before the synchronous function finishes from executing, it still goes on and execute the next line of code. Why is that?

In JavaScript, everything is a function. There is no differentiation between a synchronous and an asynchronous function.
The only difference is the way you call these functions. So "sync"/"async" is an abstract concept for programmers which makes it easier to communicate.
How JavaScript actually works:
JavaScript has a queue of "functions" that are waiting to be executed. Everytime you create a new "asynchronous function", you add it to this queue. This happens, for example, when you do a setTimeout(), an ajax call, or simply a DOM-event like "onClick" triggered by the browser.
If a specific function is executed in JS, it will never be interrupted - it runs until it finished (returned). Only afterwards, the runtime (browser) takes a look at the queue, decides which function should be executed next, and then calls it - waiting it to be finished.
In your example above, the browser is currently executing the function that will print "bar". This execution cannot be interrupted before it finished, therefore "bar" is printed first. During the execution, however, a new asynchronous function is created and pushed to the execution-queue. Only after "bar" has been printed, the runtime will look in the queue, find the "foo"-function and execute it.
A negative side effect of this are long-running tasks. While such a function is executed, nothing else can be done by the browser. Not even rendering/updating the page. So if you have a piece of code that runs for, say, 10 seconds, the user cannot interact with the website until the function finished. The reason for that is that all user events, like mouse movenent, clicks and scroll events are queued and cannot be handled until the thread finishes the long running Task.
Multithreading with JavaScript
With HTML5, JavaScript now has the opportunity to use multiple threads using web workers though. But this is an entirely different topic and out of scope for this question. Just remember that it is theoretically possible.

Is $(document).ready() executing in the main thread, or is it asynchronous?

I'm using a graph visualization library in $(document).ready() and it seems to block UI. I was expecting $(document).ready() to execute in a separate thread.
Does any one know about the details? Maybe I should use setTimeout to run the code asynchronously?
Edit:
The term "asynchronous" and "separate thread" is misleading in JavaScript. I'm not an expert of JavaScript and I can't find more accurate term. Please see the answers for clarification.

With the exception of Web Workers (which do not have direct access to DOM), JavaScript runs in a single thread. $(document).ready() is asynchronous in the sense that the callback you pass to it may fire right away or sometime later when the DOM is loaded, but when its callback actually runs, it is the only thing that the JS runtime is processing.
A long-running for loop, for instance, will block the UI thread regardless of whether it is in a ready callback, an event handler, an async XHR's success callback, etc. The only way to prevent it from blocking the thread would be to break it up into several loops by scheduling later chunks using setTimeout.

There is no separate thread in JavaScript. All JavaScript is executing in a single thread; UI updates are executing in the same thread. If your JavaScript is busy, UI updates do not happen. "asynchronous" is a bit of a misleading term here; it means that execution of a function will be deferred (but still in a single thread).
Basically, a browser has an execution queue. All event handlers are put into the execution queue when they are triggered; as are timeout functions. When any function with no callers exits, the next function in the queue is executed. UI updates are also in the same queue.
So when you do $(document).ready(fn), it (in simple terms; jQuery makes it a bit complex, especially for older browsers) will attach a handler. This handler will get triggered by the browser when all the content is loaded, which will put it onto the execution queue. When it is its turn, it will execute; any UI updates it performs will be painted when the handler exits.
--
*) There is an exception to the single-thread rule: web workers. Each web worker runs in its own thread, but they are very limited as to what they can do; basically, computation only (they can't access UI at all).

Asynchronous doesn't mean multithread. Javascript is event based, functions will be called when something happens (an event occurs). The event listening function is not executed on a separate thread, its just planned to be executed later.
But there one old technique to emulate multithread without the browser support for Web Workers. It's splitting up one whole task into deferring small tasks.
For example, you write this which will cause blocking:
for (var i = 0; i < 10000000; i++) {
// do something very slow
}
Turn it to this, and it will execute parallel, almost like multithreaded.
(function step(i) {
if (i < 10000000) {
// do something very slow
setTimeout(function() {step(i + 1)}, 1);
}
})(0);
Edit: I just realized that this will cause memory problem, because in each step closure we are referencing the previous step, making it impossible for the GC to clean up memory. To overcome this, put i out of the arguments, and change it like this (I'm wrapping the whole thing with a function, so that i can not be changed mistakenly outside):
(function() {
var i = 0;
(function step() {
if (i < 10000000) {
// do something very slow
i++;
setTimeout(step, 1);
}
})();
})();

Understanding the Event Loop

I am thinking about it and this is what I came up with:
Let's see this code below:
console.clear();
console.log("a");
setTimeout(function(){console.log("b");},1000);
console.log("c");
setTimeout(function(){console.log("d");},0);
A request comes in, and JS engine starts executing the code above step by step. The first two calls are sync calls. But when it comes to setTimeout method, it becomes an async execution. But JS immediately returns from it and continue executing, which is called Non-Blocking or Async. And it continues working on other etc.
The results of this execution is the following:
a c d b
So basically the second setTimeout got finished first and its callback function gets executed earlier than the first one and that makes sense.
We are talking about single-threaded application here. JS Engine keeps executing this and unless it finishes the first request, it won't go to second one. But the good thing is that it won't wait for blocking operations like setTimeout to resolve so it will be faster because it accepts the new incoming requests.
But my questions arise around the following items:
#1: If we are talking about a single-threaded application, then what mechanism processes setTimeouts while the JS engine accepts more requests and executes them? How does the single thread continue working on other requests? What works on setTimeout while other requests keep coming in and get executed.
#2: If these setTimeout functions get executed behind the scenes while more requests are coming in and being executed, what carries out the async executions behind the scenes? What is this thing that we talk about called the EventLoop?
#3: But shouldn't the whole method be put in the EventLoop so that the whole thing gets executed and the callback method gets called? This is what I understand when talking about callback functions:
function downloadFile(filePath, callback)
{
blah.downloadFile(filePath);
callback();
}
But in this case, how does the JS Engine know if it is an async function so that it can put the callback in the EventLoop? Perhaps something like the async keyword in C# or some sort of an attribute which indicates the method JS Engine will take on is an async method and should be treated accordingly.
#4: But an article says quite contrary to what I was guessing on how things might be working:
The Event Loop is a queue of callback functions. When an async
function executes, the callback function is pushed into the queue. The
JavaScript engine doesn't start processing the event loop until the
code after an async function has executed.
#5: And there is this image here which might be helpful but the first explanation in the image is saying exactly the same thing mentioned in question number 4:
So my question here is to get some clarifications about the items listed above?

1: If we are talking about a single-threaded application, then what processes setTimeouts while JS engine accepts more requests and executes them? Isn't that single thread will continue working on other requests? Then who is going to keep working on setTimeout while other requests keep coming and get executed.
There's only 1 thread in the node process that will actually execute your program's JavaScript. However, within node itself, there are actually several threads handling operation of the event loop mechanism, and this includes a pool of IO threads and a handful of others. The key is the number of these threads does not correspond to the number of concurrent connections being handled like they would in a thread-per-connection concurrency model.
Now about "executing setTimeouts", when you invoke setTimeout, all node does is basically update a data structure of functions to be executed at a time in the future. It basically has a bunch of queues of stuff that needs doing and every "tick" of the event loop it selects one, removes it from the queue, and runs it.
A key thing to understand is that node relies on the OS for most of the heavy lifting. So incoming network requests are actually tracked by the OS itself and when node is ready to handle one it just uses a system call to ask the OS for a network request with data ready to be processed. So much of the IO "work" node does is either "Hey OS, got a network connection with data ready to read?" or "Hey OS, any of my outstanding filesystem calls have data ready?". Based upon its internal algorithm and event loop engine design, node will select one "tick" of JavaScript to execute, run it, then repeat the process all over again. That's what is meant by the event loop. Node is basically at all times determining "what's the next little bit of JavaScript I should run?", then running it. This factors in which IO the OS has completed, and things that have been queued up in JavaScript via calls to setTimeout or process.nextTick.
2: If these setTimeout will get executed behind the scenes while more requests are coming and in and being executed, the thing carry out the async executions behind the scenes is that the one we are talking about EventLoop?
No JavaScript gets executed behind the scenes. All the JavaScript in your program runs front and center, one at a time. What happens behind the scenes is the OS handles IO and node waits for that to be ready and node manages its queue of javascript waiting to execute.
3: How can JS Engine know if it is an async function so that it can put it in the EventLoop?
There is a fixed set of functions in node core that are async because they make system calls and node knows which these are because they have to call the OS or C++. Basically all network and filesystem IO as well as child process interactions will be asynchronous and the ONLY way JavaScript can get node to run something asynchronously is by invoking one of the async functions provided by the node core library. Even if you are using an npm package that defines it's own API, in order to yield the event loop, eventually that npm package's code will call one of node core's async functions and that's when node knows the tick is complete and it can start the event loop algorithm again.
4 The Event Loop is a queue of callback functions. When an async function executes, the callback function is pushed into the queue. The JavaScript engine doesn't start processing the event loop until the code after an async function has executed.
Yes, this is true, but it's misleading. The key thing is the normal pattern is:
//Let's say this code is running in tick 1
fs.readFile("/home/barney/colors.txt", function (error, data) {
//The code inside this callback function will absolutely NOT run in tick 1
//It will run in some tick >= 2
});
//This code will absolutely also run in tick 1
//HOWEVER, typically there's not much else to do here,
//so at some point soon after queueing up some async IO, this tick
//will have nothing useful to do so it will just end because the IO result
//is necessary before anything useful can be done
So yes, you could totally block the event loop by just counting Fibonacci numbers synchronously all in memory all in the same tick, and yes that would totally freeze up your program. It's cooperative concurrency. Every tick of JavaScript must yield the event loop within some reasonable amount of time or the overall architecture fails.

Don't think the host process to be single-threaded, they are not. What is single-threaded is the portion of the host process that execute your javascript code.
Except for background workers, but these complicate the scenario...
So, all your js code run in the same thread, and there's no possibility that you get two different portions of your js code to run concurrently (so, you get not concurrency nigthmare to manage).
The js code that is executing is the last code that the host process picked up from the event loop.
In your code you can basically do two things: run synchronous instructions, and schedule functions to be executed in future, when some events happens.
Here is my mental representation (beware: it's just that, I don't know the browser implementation details!) of your example code:
console.clear(); //exec sync
console.log("a"); //exec sync
setTimeout( //schedule inAWhile to be executed at now +1 s
function inAWhile(){
console.log("b");
},1000);
console.log("c"); //exec sync
setTimeout(
function justNow(){ //schedule justNow to be executed just now
console.log("d");
},0);
While your code is running, another thread in the host process keep track of all system events that are occurring (clicks on UI, files read, networks packets received etc.)
When your code completes, it is removed from the event loop, and the host process return to checking it, to see if there are more code to run. The event loop contains two event handler more: one to be executed now (the justNow function), and another within a second (the inAWhile function).
The host process now try to match all events happened to see if there handlers registered for them.
It found that the event that justNow is waiting for has happened, so it start to run its code. When justNow function exit, it check the event loop another time, searhcing for handlers on events. Supposing that 1 s has passed, it run the inAWhile function, and so on....

The Event Loop has one simple job - to monitor the Call Stack, the Callback Queue and Micro task queue. If the Call Stack is empty, the Event Loop will take the first event from the micro task queue then from the callback queue and will push it to the Call Stack, which effectively runs it. Such an iteration is called a tick in the Event Loop.
As most developers know, that Javascript is single threaded, means two statements in javascript can not be executed in parallel which is correct. Execution happens line by line, which means each javascript statements are synchronous and blocking. But there is a way to run your code asynchronously, if you use setTimeout() function, a Web API given by the browser, which makes sure that your code executes after specified time (in millisecond).
Example:
console.log("Start");
setTimeout(function cbT(){
console.log("Set time out");
},5000);
fetch("http://developerstips.com/").then(function cbF(){
console.log("Call back from developerstips");
});
// Millions of line code
// for example it will take 10000 millisecond to execute
console.log("End");
setTimeout takes a callback function as first parameter, and time in millisecond as second parameter.
After the execution of above statement in browser console it will print
Start
End
Call back from developerstips
Set time out
Note: Your asynchronous code runs after all the synchronous code is done executing.
Understand How the code execution line by line
JS engine execute the 1st line and will print "Start" in console
In the 2nd line it sees the setTimeout function named cbT, and JS engine pushes the cbT function to callBack queue.
After this the pointer will directly jump to line no.7 and there it will see promise and JS engine push the cbF function to microtask queue.
Then it will execute Millions of line code and end it will print "End"
After the main thread end of execution the event loop will first check the micro task queue and then call back queue. In our case it takes cbF function from the micro task queue and pushes it into the call stack then it will pick cbT funcion from the call back queue and push into the call stack.

JavaScript is high-level, single-threaded language, interpreted language. This means that it needs an interpreter which converts the JS code to a machine code. interpreter means engine. V8 engines for chrome and webkit for safari. Every engine contains memory, call stack, event loop, timer, web API, events, etc.
Event loop: microtasks and macrotasks
The event loop concept is very simple. There’s an endless loop, where the JavaScript engine waits for tasks, executes them and then sleeps, waiting for more tasks
Tasks are set – the engine handles them – then waits for more tasks (while sleeping and consuming close to zero CPU). It may happen that a task comes while the engine is busy, then it’s enqueued. The tasks form a queue, so-called “macrotask queue”
Microtasks come solely from our code. They are usually created by promises: an execution of .then/catch/finally handler becomes a microtask. Microtasks are used “under the cover” of await as well, as it’s another form of promise handling. Immediately after every macrotask, the engine executes all tasks from microtask queue, prior to running any other macrotasks or rendering or anything else.