Develop Reference

How is a function made inherently asynchronous in JavaScript

I have been trying to understand how asynchronous JavaScript works. From what I understand, the language is by-default synchronous and single-threaded.
Synchronous in the sense that during the processing of the current task, rest of the code is blocked.
Single-Threaded in the sense that only one sequence of functions is loaded at a time. To me, both of these concepts sound a bit similar.
I'm aware of how callbacks, promises and async/await keywords help in dealing with asynchronous code. But what I don't understand is, how a block of code is made asynchronous. For example, this is a code from javascript.info:
function loadScript(src) {
// creates a <script> tag and append it to the page
// this causes the script with given src to start loading and run when complete
let script = document.createElement('script');
script.src = src;
document.head.append(script);
}
Now, when this function is called, it is supposed to be "asynchronous", in the sense that it won't block the subsequent lines of code from execution, but will carry on it's work "in the background".
loadScript('/my/script.js');
// the code below loadScript
// doesn't wait for the script loading to finish
// ...
What I don't understand is, what part of the function defined above made it asynchronous? The same goes for browser and API functione like fetch() and addEventListener(). What in their implementation made them asynchronous? How is task made to be performed in the background without blocking the rest of the code?

"What part of the function defined above made it asynchronous?"
The above function runs synchronously, but this calls for explanation. In general:
Event Loop
Browsers use an event loop to process "everything", including repainting the screen,
calling JavaScript code when timers expire, promises become settled, events have occurred and need to be fired on DOM elements, or in general calling JavaScript in response to an external event.
Single Thread
The event loop's task manager does not continue with other tasks after passing control to the JavaScript engine to execute JavaScript code. This is the "single threaded" part. JavaScript execution continues until it runs to completion, either by running to the end of top-level execution flow within a script element, or by returning from a call out from the event loop.
Single threading prevents JavaScript execution being interrupted by call outs from the event loop in a different thread with the ability to access the same program scope - which has the potential to corrupt data and program state. Effectively single threading eliminates the need to implement a disable/enable interrupts system in JavaScript.
Note: Multiple JavaScript threads can be created by setting up worker threads running in separate CPU threads. But communication between threads is tightly controlled and they do not share the same program scope.
Blocking
The cost of single threading is that execution of JavaScript in the main thread prevents the event loop task manager from proceeding with anything else. Hence executing JavaScript will block screen updating and responding to user input etc. until it returns to the event loop.
Synchronous
Synchronous code means code executed in a single call out from the event loop. Synchronous code execution flow proceeds through sequential, branch and looping constructs as you would read it in source code.
A synchronous API call is one that returns it result back to the caller with a return statement - without using a callback function or promise to supply the result.
Asynchronous
Asynchronous code is relative to something else: it is code that is not executed in the same call out from the event loop as some other execution context. E.G. a call back function passed to setTimeout is never called before the code that calls setTimeout returns to the event loop, so the call back is said to be called "asynchronously".
async Functions
Functions declared with the async keyword are a special case by design. Briefly
the await operator returns to the event loop when executed. Hence code using the result of an await operator runs asynchronously with respect to code which executed the await operator (or prepared its operand).
async functions always return a promise for the function's return value, not the returned value itself. Since promise values are not available synchronously, async function results can not be obtained synchronously in calling code.
For parts of the question:
What part of a function makes it asynchronous?
Standard functions are not inherently asynchronous: it is how they are called that determines their synchronicity or otherwise. Describing a standard function as an "asynchronous function" would mean it is intended to be called asynchronously. Calling an async function an "asynchronous function" is a simplification: async functions are often called synchronously but always involve asynchronous code execution.
API functione like fetch() and addEventListener()
document.addEventListener("click", event=>console.log("clicked"))
adds the anonymous arrow function as a click event listener. Because the arrow function not called as part of the above script's execution flow, you can say it's called asynchronously when a user clicks the mouse.
Similar considerations apply to fetch: the code calling fetch returns to the event loop, the browser initiates a network request, waits for a response, places a task in a task queue and the event loop task manager calls the fetch callback with data. The callback runs asynchronously with respect to the code that called fetch in the first place.
function loadScript(src) {
// creates a <script> tag and append it to the page
// this causes the script with given src to start loading and run when complete
let script = document.createElement('script');
script.src = src;
document.head.append(script);
}
A call to loadScript will execute the function's body code and synchronously return to the caller which continues execution after the call. It does however have side effects:
If loadScript is called while parsing HTML source, the absence of an async attribute on the script element means the HTML parser will stop parsing further HTML source until after the script has been fetched from the location specified in src, parsed by the JavaScript parser and executed. However execution of the loaded script is asynchronous: it only executes after the code calling loadScript returns to the event loop.
If the above code is executed after HTML parsing has reached end of input, the async attribute value is ignored and the script will be loaded asynchronously anyway. Placing "load" and "error" handlers on the script element allows obtaining notification of script load success or failure.

Which part of the Javascript runtime is responsible for putting the callback into the callback queue?

Consider this code running on the chrome console:
function main(){
setTimeout(()=>console.log('Hello World!'), 5000);
};
main();
As per my understanding:
The V8 engine will push main() into the call stack.
The setTimeout() web API binding will be called by the engine, which in turn will trigger some native code outside of the main javascript thread.
main() will be popped off the stack
Once the 5 seconds has elapsed, the event loop will retrieve the callback from the callback queue and add it onto the call stack for execution.
My question (which I think is a very minute detail, but has been bugging me for awhile) at which point and by whom is the callback pushed onto the callback queue?

You can think of the event loop as this piece of pseudo-code at the core of the JavaScript engine:
while (true) {
while (queue.length === 0) {
sleep(); // Native way to let the current process sleep.
}
callback = queue.pop_first();
callback();
}
And then the engine exposes a public function to its embedder:
function ScheduleCallback(callback) {
queue.push_last(callback);
}
I'm obviously glossing over a bunch of details here (synchronization of queue access, waking up when something gets queued, graceful termination, prioritization of callbacks, ...), but that's the general gist of it.
To implement setTimeout, an embedder would use some other primitive that provides a waiting function (e.g. it could spin up a thread and put that thread to sleep for the desired time, or it could rely on a function similar to setTimeout provided by the operating system, i.e. some way to trigger a callback after a specified amount of time), and then call the function mentioned above. In pseudo-code:
engine.global.setTimeout = function(callback, delay) {
OS.kernel.setTimeout(delay, () => {
engine.ScheduleCallback(callback);
});
}
This also explains why timeouts are not guaranteed to be precise: firstly, the operating system's timer primitive might have its own granularity constraints and/or might simply be busy; secondly the best an embedder can do is to schedule the callback after the specified time, but if your event loop is currently busy executing something else, then the scheduled callback will have to wait in the queue for its turn.
Side note: "pushing a function onto the call stack" is exactly the same as calling it; "popping it off the call stack" is exactly the same as having it return. The line "callback();" in the first snippet above does both. It's that simple!

As JavaScript is not multithreaded, a callback can't be called at any time or run in parallel to other code of the same "context".
As of that a callback function that is passed to some external code can't be called at any time by that external code, that call has to be initiated by the engine. To give the code execution some predict/reliable execution order, the engine uses the even loop for that.
How this is handled depends on the engine, the engine could tell the external code to check if there are callbacks to be called, and ask to call them. But that might result in undesirable groupings of callbacks. Or that external code could pass those callbacks that should be called back to the engine which stores them in a queue.

where do the browser web api's run in Javascript?

where do the browser web api's run in Javascript like setTimeout ?
Do they run in some other environment or they take the help of javascript single thread ?

They run outside of the JavaScript runtime. Those "Web API's" are executed within the browser's Web API execution space.
setTimeout() for example, is a method of the window object (it can also be invoked as window.setTimeout()). window is not at all part of JavaScript (it's a browser object) and anything you ask the window to do for you is handled outside of the JavaScript runtime and by the browser's other capabilities. The request for the Web API call originates from within the JavaScript environment, but the execution of the API call actually runs outside of it.
This is the very reason that we can have asynchronous behavior in web applications. While the JavaScript runtime (which is a synchronous environment that can only do one thing at a time) is doing its one thing, the browser can be doing something else.
setTimeout(), alert(), navigator.geolocation, XMLHttpRequest are all examples of Web APIs that run outside of the JS engine.
Here are some other Web API's and here is a great video that explains this in the context of timers specifically.

The following series of events occur when the API calls are made:
When the browser makes an API call, the API call is placed in the call stack
API call is placed in the browser's web APIs stack for execution in the background
While the API call is being executed in web APIs background, the render queue tasks are passed to the call stack by the event loop (assuming all tasks in call stack are complete) - this means the render queue is not actively paused hence the browser is not freeze
Once the API call is completed, the results are placed to the callback queue
If the call stack is clear, the results of the API response are placed to the call stack and the API response handler is executed by the call stack
Do comment if you need any clarification

APIs in client-side JavaScript:
To understand how browser APIS works, first, you have to clear concept about execution stack, event loop and message queue
Client-side JavaScript, in particular, has many APIs available to it — these are not part of the JavaScript language itself, rather they are built on top of the core JavaScript language, providing you with extra superpowers to use in your JavaScript code. They generally fall into two categories:
Browser APIs are built into your web browser and are able to expose data from the browser and surrounding computer environment and do useful complex things with it.
For example, the Web Audio API provides JavaScript constructs for manipulating audio in the browser — taking an audio track, altering its volume, applying effects to it, etc. In the background, the browser is actually using some complex lower-level code (e.g. C++ or Rust) to do the actual audio processing. But again, this complexity is abstracted away from you by the API.
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Introduction
<script>
const second = () =>{
console.log("How are you doing");
}
const first = () =>{
console.log("Hi there");
second();
console.log("The End");
}
first();
</script>
Above example is an example of Synchronous JavaScript, where the first function is executed, logs "Hi There!" to the console, calls the second function, which then prints "How are you doing?" to the console,
nd then finally "The end" is logged to the console One instruction after the other in a Synchronous way.
Now let's try by an example with setTimeout which is a web API. considering bellow example
<body>
<script>
const second = () =>{
setTimeout(()=>{
console.log("Async Hi there");
}, 2000)
}
const first = () =>{
console.log("Hi there");
second();
console.log("The End");
}
first();
</script>
</body>
Output:
Now above one involves some Asynchronous JavaScript. Again the first function gets called, logs "Hi There!" to the console, and then calls the second function. Now this function calls the Set Timeout function, which is basically like a timer that will execute the callback function that we passed into it, after 000 milliseconds. However, this will not make the code stop for two seconds, but instead, the function returns, goes back to the first function and logs "The end". Then after the two seconds actually have passed, Async "Hi There!" is logged to the console.
Now, why does the code move on, instead of waiting for the timer to finish?
Well, before I discuss with you how and why this actually works behind the scenes, let me quickly explain to you another example. Suppose we select an image from our DOM and pass it into a Process Large Image function,
that we created. We know that this function is gonna take some time
to process the image. And just like before we don't want the code to have to wait. So we don't want it to stop while the image is processing,
because that would be terrible in some situations. What we do here is to also pass in a Callback function, that we want to be called as soon as the function is done processing. And just like that we have created Asynchronous code.
That is the whole philosophy behind Asynchronous JavaScript. We do not wait for a function to finish its work, and then do something with the result. Instead, we let that function do its job in the background,
so that we can move on with the code execution. We then also pass in a callback function, that will be called as soon as the main function
has done whatever it had to do. We then move on immediately,
so that the code is never blocked. Which means that it can keep processing the code in a Synchronous way, line by line. Because if the code is actually blocked, then nothing really works on the page during that time.
For example you can't click any buttons, or anything like that. So, in summary, we can use callback functions to defer actions into the future.
In order to make our code non-blocking. But how does that actually work
behind the scenes of JavaScript? Well, that's where the Event Loop comes in. the Event Loop is part of the bigger picture of what happens behind the scenes of JavaScript, when we call functions and handle events like DOM events.
Event Loop, as well as the Web APIs, which together with the Execution Stack and the Message Queue make up our JavaScript runtime. This runtime is responsible for how JavaScript works behind the scenes as it executes our code. It's extremely important to understand how all these pieces
fit together in order to execute Asynchronous JavaScript.
Let's now take a look at how the code from the last example
is executed inside our JavaScript engine, line by line.
It starts by calling the first function, and as we already know,
an Execution Context for that function is put on top of the Execution Stack, which can also be called the Call Stack.
In the next line of code, the console dot log function is called and a new Execution Context is created and the text is logged to the console.
Then the function returns and the Execution Context pops off the stack.00
Moving on to the second function, a new Execution Context is created
and in the next line the Set Timeout function is called. Which causes yet another Execution Context to be created.
Now, before we move on, where does this Set Timeout function actually come from? It's part of something called the Web APIs. Which actually live outside the JavaScript engine itself. Stuff like DOM manipulation methods, Set Timeout, HTTP requests for AJAX, geolocation, local storage and tons of other things, actually live outside of the JavaScript engine
We just have access to the because they are also in a JavaScript runtime
This is exactly where the time will keep running for two seconds, asynchronously of course so that our code can keep running without being blocked.
When we call the Set Timeout function the timer is created, together of course with our callback function Right inside the Web APIs environment.
And there it keeps sitting unti it finishes its work all in an Asynchronous way.
The callback function is not called right not but instead it stays attached to the timer until it finishe
And since the timer keeps working basically in the background, we don't have to wait and can keep executing our code. Next up, the Set Timeout function returns, pops off the stack and so does the Execution Context of the second function Which now returns as well and we are back to the initial first function. Now we just log the end to the console
and we give ourselves a new Execution Context, print the text to the console and pop the text off again.
Next the function returns and we are back to our original state
Right now we have executed all our code in a Synchronous way,and have the timer run Asynchronously in the background. Let's suppose that our two seconds have passe and the timer disappear. But what happens to our callback function no Well, it simply moves to the Message Queue
where it waits to be execute as soon as the Execution Stack is empty
This is exactly what happens with DOM events.
In the case of DOM events our event listeners sit in the Web APIs environment, waiting for a certain event to happen And as soon as that event then happen then the callback function is placed on a Message Queue
ready to be execute.
Alright, so how are these callback function in the Message Queue executed
And that's where, finally, the Event Loop comes in. The job of the Event Loop is to constantly monitor the Message Queue and the Execution Stack,
and to push the first callback function in line onto the Execution Stack, as soon as the stack is empty. In our example here, right now the stack is empty, right And we have one callback waiting to be execute
And the event loop takes the callback and pushes it onto the stack
where a new Execution Context is created for that function.
That's what the event loop does. Inside that callback function now,
we simply run the log function, which logs Async "Hi There!" to the console. Then the context pops off the stack and we're done! Now if there were some callbacks waiting right now like data coming back from an AJAX request or the handler of a DOM even then the Event Loop would continue pushing them onto the stack until all of them were processed.

How much further does code execute after an asynchronous function is called

Apologies if the title of this question is slightly confusing, I was struggling to find a way to word this.
Basically, when an asynchronous function is called, how much further down the code will be executed if the asynchronous function is called from other functions, objects, or files. For example:
function func1() {
// async function 1
// async function 2
}
function func2() {
// more code
}
func1();
func2();
Let's say we execute func1() and both the async functions inside of it take a very long time to run. Will we continue on to func2() while the content of func1() is still being run, or will we block until func1() is finished before continuing to func2()?

JavaScript is single threaded, non-blocking and asynchronous language. JavaScript has call stack, event loop and a callback queue. Words are taken directly from this video. Javascript works on v8 engine (chrome), spider monkey (firefox) which provide JavaScript call stack and heap. v8 or spider monkey provide call stack to Javascript so whenever a function is called, it is stored in the call stack of the runtime (browser in our case, local if you have node installed). Browser also provide the web apis to the javascript like setTimeOut, XMLHttpRequest and DOM. The pictorial illustration is something like this. (Source is the same video which I've tagged.)
JavaScript is single threaded and it means it can execute one function at a time as it has only one call stack. So whenever an asynchronous code (inside func1)is executing, it is executed through webAPIs provided by the browser. The role of callback queues come here. Whenever the result from the Async code is executed, it is stored in the callback queue and it waits for the stack to get empty (event driven programming). Whenever it sees that the stack is empty, the function from the callback queues will start executing.
In your case, you're calling func1, it kicks in some async code but currently func1 is in stack. If the async code has completed and if it sees the stack as empty, it will executed the async code first and then func2 but if the async code hasn't completed, it will start executing the func2 and the callback queue will wait for the stack to get empty. In this case, the flow will be func1 --> func2 --> async code.
So, it is matter of timing. For async code, if the code has returned and waiting in callback queue, as soon as it sees the stack empty, it will kick in and start executing the callbacks (.then or callback from setTimeOut etc.) I'll recommend you to watch that video for better insights and what an event loop in JS is. If I'm missing out something, anyone please feel free to edit this answer or provide suggestions for edit.

JavaScript is single threaded, it literally means nothing can be executed in the same time. If your code has asynchronous nature it means that it is executed in uknown future. I said uknown because it depends from the code. For example asynchronous code for ajax call will be executed when the browser gets the response from the server.
That said, the async code is not executed in the declaration moment but in uknown next event loop. Furthermore it not blocks the current execution. In javascript your execution code can not be disturbed. It just runs through all lines.
Going back to the example, if func1 has no sync blocking code then func2 will be executed right away without any delay.

Asynchronous callback are top level events (similar to button click events) and can only be started when there is no other scripts executing.
Execution will continue till call stack is empty (including "global user code" which what your sample shows) and script engine itself gets control back - so both func1() and func2() will finish before callbacks are executed.
Note: you can't rely on such behavior for normal code - if "asynchronous" function has both synchronous and asynchronous code branches callback from that function can be executed synchronously without even returning to calling function (this can happen with plain callbacks or any other form including promises).

Why do callbacks functions allow us to do things asynchronously in Javascript?

I've read that callbacks make JavaScript asynchronously. But I'm not sure if I understood the explanation. This is what I get
Callback functions allow us to do things asynchronously, since they ensure
that the lines prior to the callback are completely finished before loading
the next line.
Is that true? Thanks

First off, it isn't the callback that enables anything. A given operation in node.js or even browser-based javascript either is or isn't asynchronous. It really has nothing to do with the callback, though a callback is typically used to communicate results of an asynchronous operation.
For example, Javascript's array.forEach() uses a callback, but it is not asynchronous. So, async operations are async because their underlying implementation is non-blocking. You start the operation by making a function call, the operation proceeds in the background and the rest of your code continues to run. Meanwhile, when the asynchronous operation completes, it usually then needs to tell your code that it is done and perhaps communicate some results. A callback function is the chosen mechanism for communicating the completion of the async operation.
I've read that callbacks make JavaScript asynchronously.
No, that is not really true. Callbacks can be used with synchronous operations too. Just because one uses a callback does not make anything asynchronous. The underlying native code implementation of an operation must be asynchronous (such as an Ajax call or other networking operation). Callbacks are used to communicate the results of asynchronous operations. They are also have many other non-asynchronous uses too. So, a callback is just one tool used in an asynchronous operation and a callback is a tool with many other uses too. You cannot say callback === asynchronous.
Callback functions allow us to do things asynchronously, since they
ensure that the lines prior to the callback are completely finished
before loading the next line.
It is hard to tell exactly what you mean by this, but it sounds wrong to me. When using asynchronous operations, code is typically not executed in the order laid out in the file. For example, if you did this:
console.log("async start");
callSomeAsyncOperation(function(result) {
console.log("async done");
});
console.log("I'm here now");
You would see this in the log:
async start
I'm here now
async done
Callbacks and Event Queues Explained
It may also be useful to understand how an asynchronous operation works. Javascript works off an event queue. A given sequence of Javascript code runs to its completion. When that completes, the engine looks in the event queue to see if there are any more events to process. If so, the first event in the queue is pulled out and a callback that was registered for that event is called. This starts a new sequence of Javascript code running. That code continues to run until it finishes. When it finishes, the engine checks for another event. If there is one, it is then processed by calling a callback associated with that event. When there are no more events to process, the engine goes to sleep waiting for the next event. When an event occurs (outside the main Javascript thead), it is then added to the queue and that process of adding it to the queue causes the JS engine to wake up and service that event.
When writing your Javascript, you will often register and event handler for an event. The way this works in Javascript is that you say what event you're interested in (which may also include specifying some other information like what object you're looking for events on) and then you pass it is a function reference. You are, in essence, telling the Javascript engine that you want it to call your function reference when this event occurs. This type of function reference is referred to as a "callback". It's just a normal function, but the context in which it is being used is called a "callback" because some other code will "call you back" at some time in the future by executing your function. You can then place appropriate code in that function reference (inside that callback function) that can respond to that event. Depending upon the type of event, you may only get called once or it may call you every time that event occurs.
You can read more about how this event queue and callbacks work in these references:
Run Arbitrary Code While Waiting For Callback in Node?
blocking code in non-blocking http server
Hidden threads in Javascript/Node that never execute user code: is it possible, and if so could it lead to an arcane possibility for a race condition?
How does JavaScript handle AJAX responses in the background? (written about the browser, but concept is the same)

First of all, let's understand what callback is (by definition):
In computer programming, a callback is a piece of executable code that
is passed as an argument to other code, which is expected to call back
(execute) the argument at some convenient time. The invocation may be
immediate as in a synchronous callback, or it might happen at later
time as in an asynchronous callback. In all cases, the intention is to
specify a function or subroutine as an entity that is, depending on
the language, more or less similar to a variable.
Now, talking about Javascript, not always a callback is asynchronous. For example:
function syncOperation(callback) {
callback();
}
syncOperation(function() {
console.log('a');
console.log('b');
});
console.log('c');
That callback is synchronous, since it doesn't make any asynchronous operation. If you open your console and run the code above, you'll see that it will log a, then b, then c.
Now, let's see an asynchronous example:
function asyncOperation(callback) {
setTimeout(callback, 0);
}
asyncOperation(function() {
console.log('a');
console.log('b');
});
console.log('c');
You'll see firstly c, then a, and b. That's because the setTimeout function runs asynchronously.
Some built-in Javascript functions are asynchronous, and they will run, and at some time, they will call the function you passed as parameter back. That's why if you do:
var a = 'text';
setTimeout(function() { a = 'new text'; }, 0);
console.log(a);
You'll see in your console text, because it will run before the variable has been changed.