How Does JavaScript Actually Execute Code?

When I first started learning JavaScript, I thought it just… ran line by line, top to bottom. Simple, right? But the deeper I went, the more I realized there’s a fascinating system under the hood.

If you’ve ever wondered how JavaScript actually executes your code in the browser, let’s walk through it together.

JavaScript Runs on a Single Thread

First thing to know: JavaScript is single-threaded. In plain English, it can only do one thing at a time.

So if you write:

console.log("Hello");
console.log("World");

It’s going to print “Hello” first, then “World.” No surprises there.

But then you might ask:
“How the heck does it handle things like timers, API requests, or user clicks without blocking everything?”

Good question. That’s where the event loop comes into play. But hold that thought for now we’ll get there.

Meet the JavaScript Engine

Your code doesn’t magically run by itself. Browsers (and Node.js) use something called a JavaScript engine.

• Chrome and Node.js use V8.

• Firefox uses SpiderMonkey.

• Safari uses JavaScriptCore.

The engine basically:

1. Reads your code (parsing).

2. Translates it into machine-friendly instructions.

3. Runs it efficiently.

So when you type console.log("Hello"), the engine is the one doing the actual work.

Execution Contexts: The Stage for Your Code

Here’s where it gets interesting. JavaScript doesn’t just “run” code, it sets up an execution context. Think of it as the environment where your code lives.

There are two main ones:

• Global Execution Context – created when your script starts.

• Function Execution Context – created whenever you call a function.

Each context has two phases:

• Creation phase: JavaScript sets up memory space for variables and functions (this is why variables are “hoisted”).

• Execution phase: It actually runs the code line by line.

This is why you can call a function before declaring it, but you can’t access a let variable before it’s defined.

The Call Stack: JavaScript’s To-Do List

JavaScript keeps track of where it is in the program using something called the call stack.

• When your script starts, the global context goes on the stack.

• When you call a function, its context gets added on top.

• When the function finishes, it gets removed.

If you’ve ever seen a “stack overflow” error (yes, the site is named after it), it happens when the stack fills up.

Synchronous vs Asynchronous Code

Most of the time, JavaScript runs synchronously.

But when you throw in things like setTimeout or fetch, JavaScript doesn’t just sit there waiting. It hands those tasks over to Web APIs (provided by the browser).

Example:

console.log("Start");

setTimeout(() => {
  console.log("Inside setTimeout");
}, 1000);

console.log("End");

The output?

Start
End
Inside setTimeout

Even though we told it to wait a second, JavaScript didn’t block. It kept going, then picked up the callback later.

Enter the Event Loop

Here’s the magic:

• The Call Stack handles synchronous code.

• Web APIs take care of async tasks.

• Finished async tasks move into the Callback Queue.

• The Event Loop keeps checking: if the stack is empty, it pulls something from the queue and runs it.

That’s why your app doesn’t freeze while waiting for an API response.

Big Picture

To sum it up, when you run JavaScript code:

1. The engine parses and compiles it.

2. A global execution context is created.

3. Functions create their own contexts on the call stack.

4. Web APIs handle async work.

5. The event loop moves completed tasks back onto the stack.

And that’s how JavaScript despite being single threaded, feels super-fast and responsive.

Final Thoughts

Understanding this model completely changed how I write code. Suddenly, bugs with async code made sense. I stopped fearing setTimeout tricks, and async/await felt less like magic.

So the next time you’re debugging or writing JavaScript, remember: there’s an engine, a call stack, and a little event loop tirelessly moving things around behind the scenes. Pretty cool, right?