Skip to main content

Understanding Code Execution in Javascript

If you are doing any form of programming in Javascript then understanding its eventloop is very important.

Any javascript engine has three kinds of memory models:


  1. Stack, which has the current function pointer an gets executed sequentially.
  2. Heap, this stores all the objects, functions basically anything that is initiated is stored here.
  3. Queue, all things to be executed is stored here and stack picks up tasks to do from the queue.
So, to understand this further, when a function is getting executed its loaded in the stack and if it encounters any setTimeouts then it would be added in the queue and when the current stack gets empty then the new function to be executed from the queue.

This code run will explain the process:

console.log("Add this code to queue");

setTimeout(function() {                                                //This goes and sits in the queue.
                           console.log("Running next event from the queue.");
                 },0);

function a(x) {
     console.log("Function a added to the stack!");
     b(x);
     console.log("Function a removed from the stack!");
}

function b(x) {
      console.log("Function b is added to the stack.");
      console.log("Value passed is "+x);
      console.log("Function b is removed from the stack.");
}

console.log("starting work for this stack");
a(22);
console.log("Stopping work for this stack. stack would be empty after this.");


The output of this code is self explanatory:


Add this code to queue 
starting work for this stack 
Function a added to the stack! 
Function b is added to the stack. 
Value passed is 22 
Function b is removed from the stack. 
Function a removed from the stack! 
Stopping work for this stack. stack would be empty after this. 
Running next event from the queue. 


So what happened here?
Stack is initialized with current code.
Only thing to notice is that at setTimeout call anonymous function is added to the queue. //Remember closures.
Then the function a is added to the heap.
Then function b is added to the heap.
a is called that means from heap function a is loaded on the stack.
b is called that means from heap function b is loaded on the stack.
b is removed from the stack.
a is removed from the stack.
current code execution gets over, stack becomes empty.
next execution is loaded on the stack from the queue.

This should help one understand how JS memory model works

Popular posts from this blog

Why India Hasn’t Built Its GPT Moment (Yet)

India has the world’s third-largest startup ecosystem, a thriving developer base, and a mobile-first population larger than the US and Europe combined. Yet, no GPT-4. No DeepMind. No Amazon-style platform. Why? Innovation Isn’t Accidental—It’s Engineered The Zerodha Daily Brief recently asked why India hasn’t built a global product company like Apple. The key argument: India isn’t building for the world. It’s solving for local constraints, scale, and affordability—but global scale requires deep IP, design, and tech differentiation. It’s not just about software, it’s about systems thinking. More importantly, it answers the question: Why do countries innovate? The answer isn’t just genius or ambition—it’s incentives and ecosystems. The U.S. Defense Department, for example, accounted for nearly 70% of federal R&D funding during the Cold War. China has pumped billions into semiconductors and AI with long-term national alignment. These aren’t short-term bets—they are strategic, delibe...

The Death of the Stubborn PM

Product Management is undergoing a seismic shift, much like programming did when compilers replaced assembly language or when Agile dismantled waterfall dogma. Stubborn PMs who cling to outdated rituals—like treating PRDs as sacred texts—will fade into irrelevance. The future belongs to those who embrace AI as a collaborator, not a threat.   AI Will Disrupt the Tactics, Not the Thinking   Historically, tools abstracted manual work: compilers automated code translation, A/B testing replaced gut-driven debates. Similarly, AI will automate tactical PM tasks—data aggregation, routine prioritization, even drafting specs. But this is liberating, not limiting.   The stubborn PM obsesses over *how* to write a PRD; the adaptive PM focuses on *why* a product should exist. AI can’t replicate judgment calls that demand intuition: interpreting unmet customer needs, balancing ethics with growth, or navigating ambiguity when data is sparse. As AI handles execution, the PM...

From Stubborn to Smart: How I Learned to Use AI as a PM

Listen to the article in podcast format on PM-AI Diaries channel on Spotify! Ever since I published "The Death of the Stubborn PM" back in February, my inbox has been buzzing with one big question: “Okay, I get that AI is the future for product managers—but how do I actually use it?” It’s a fair ask. In that piece, I argued that PMs who resist AI are doomed to fade away, like dinosaurs refusing to evolve. As I wrote, “The stubborn PM who clings to old ways will die out, replaced by those who harness AI’s power while leaning into what makes us human.” Now, people want the playbook. So, let’s walk through it with a story—my own journey of figuring this out, backed by some sharp insights from MIT Sloan’s "When Humans and AI Work Best Together—and When Each Is Better Alone" . The Wake-Up Call Picture me a few months back: a PM buried in work, juggling a dozen tasks, and feeling like there weren’t enough hours in the day. Writing user stories, sketching ideas, track...