let a = true;
setTimeout(() => {a = false}, 1000)
while(a){console.log(a)}
Let's see this step by step (if this was executed in browsers) :-
let a = true;
setTimeout(() => {a = false}, 1000)
while(a){console.log(a)}
let a = true; : You initialized a new variable a to true;
setTimeout(() => {a = false}, 1000) : You have told the browser's setTimeout Web API to execute a callback (() => {a = false}) in which we set a to false after minimum of 1 second. Minimum because that callback will not execute unless the JavaScript execution stack (This is where all your JS code is actually executed synchronously) is empty. This callback after 1s gets placed in an event queue and is dequeued from there only when the JavaScript execution stack is empty.
while(a){console.log(a)} : This will execute synchronously and block the main thread (where the execution stack is) since a is always true. Our main thread getting blocked means the completion of this operation is too expensive (makes sense since it's infinite logging) and so the JavaScript execution stack couldn't ever be free for any callback available in the event queue. That means () => {a = false} even though available in the event queue will never get a chance to be dequeued and run in our JavaScript execution stack.
The browser's Web API, this JavaScript execution stack and the event queue together forms our event loop for browsers.
JavaScript is single-threaded (remember main thread ?) synchronous language. All the asynchronous behaviour that you see in your web apps or servers is because of the other parts which form the event loop.
Also this is a simplified picture of it. There are more divisions to the event queue but that's beyond the scope of this question.