How JavaScript Runs Your Code

Your JavaScript file arrives at the browser as plain text. A few milliseconds later, things are happening on screen. This lesson is about what fills that gap.

You can write code without knowing this. But you cannot debug it well, and one idea in here — that JavaScript does one thing at a time — explains a whole category of bugs that otherwise look like magic.

The engine

Every browser contains a JavaScript engine: a program whose entire job is reading your code and doing what it says. Chrome and Edge use one called V8, Firefox uses SpiderMonkey, Safari uses JavaScriptCore. Node.js uses V8 too, which is how the same language ended up on servers.

When your file arrives, the engine roughly does this:

One consequence of that second step is worth noticing. A syntax error — a missing bracket, a stray quote — stops the whole file before anything runs. Not "stops at that line": nothing at all runs, including the correct code above it. Beginners often assume the first half worked. It did not.

That is different from an error while running, where everything before the failing line has already happened.

Top to bottom, one line at a time

The engine reads your file from the top and works down. This sounds obvious and has a consequence people trip over constantly:

console.log(price); // ReferenceError: Cannot access 'price' before initialization
const price = 199;

You asked for price before the line creating it had run. The engine knows the name exists — it scanned the file first — but the value has not been set yet, so it refuses. Order matters.

The call stack

Programs are mostly functions calling other functions, and the engine has to remember where it was each time it goes into one. The call stack is how.

A stack is a pile. You add to the top and take from the top, like a stack of plates. When a function is called it is pushed onto the top; when it finishes it is removed, and the engine carries on from wherever it was underneath.

Take this:

function greet(name) {
  return "Hello, " + name;
}
 
function welcome() {
  const message = greet("Anish");
  console.log(message);
}
 
welcome();

At the moment greet is running, the stack looks like this:

greet returns, and it is removed. console.log is then pushed on, runs, and is removed. welcome finishes and is removed. The stack is empty, and the program is done.

This is also what an error message is showing you. A stack trace is the stack, printed top to bottom: the function that failed, then the one that called it, then the one that called that. Reading it from the top tells you exactly how your program arrived at the problem, which turns most debugging from guesswork into reading.

And if functions keep calling without ever returning, the stack grows until the browser gives up — Maximum call stack size exceeded. That message means a function is calling itself with no way out, and now you know precisely what it describes.

One thing at a time

There is exactly one call stack. That single fact is the most important idea in this lesson.

JavaScript is single-threaded: it does one thing at a time, and it finishes that thing before starting the next. There is no second stack running your code alongside the first.

Which means a slow piece of code blocks everything. If you write a loop that takes three seconds, then for three seconds the page cannot respond to a click, cannot update, cannot even repaint a hover. It is frozen — not crashed, just busy. You have met a page that did this.

So why do slow requests not freeze the page?

Here is the apparent contradiction. Fetching data from a server takes far longer than any loop, and yet pages stay perfectly responsive while it happens.

Because the waiting is not done by your code. Your code asks the browser to fetch something and says what to do when it arrives — and then it finishes and the stack empties. The browser does the waiting, on its own time, outside your program. When the answer comes back, it puts your "what to do next" onto the now-empty stack and it runs.

That is asynchronous code, and it has a lesson of its own at the end of this track. For now, hold the distinction: waiting does not block, because the browser does it for you. Working does block, because only your code can do it.

Watch the order for yourself

This is the clearest demonstration of everything above. Predict the output before you run it — most people get it wrong the first time.

The numbers print in order, which is the surprise: the setTimeout is written before 3 but runs after it, even asking for a delay of zero.

Because it is not a delay of zero. It means "when the stack is empty, run this". Your remaining code runs first — always — and only then does the waiting function get its turn. There is no amount of zero you can ask for that jumps the queue.

What to take away

The engine reads your whole file first, so syntax errors stop everything before it starts. Code runs top to bottom. The call stack tracks which functions are in progress, newest on top, and printing it is what a stack trace does. There is only one stack, so slow code freezes the page — but waiting is handed to the browser, which is why network requests do not.

Next, you write and run your own code for the first time.