JavaScript Execution Context: Memory Creation & Execution Phases

Understood Hoisting in a much deeper way — not just definition, but what actually happens inside the JavaScript engine 👇 🧸 Imagine JavaScript like a teacher in a classroom Before teaching, the teacher prepares a register (memory) and writes all names first. 👉 JavaScript does the same thing before running code. 🧠 Behind the scenes (Real Concept): JavaScript runs in 2 phases: 1️⃣ Memory Creation Phase 2️⃣ Execution Phase ⚙️ During Memory Creation Phase: JavaScript creates something called an Execution Context (inside the Call Stack) Inside it, memory is allocated: 1- var → stored as undefined 2- let & const → stored but not initialized (Temporal Dead Zone) 3- functions → stored with full definition 💡 Example: console.log(a); var a = 10; 👉 Memory phase: a = undefined 👉 Execution phase: prints undefined 💡 Another example: console.log(b); let b = 20; 👉 Memory phase: b exists but is not initialized 👉 Execution phase: ❌ ReferenceError (because of Temporal Dead Zone) 💡 Functions: sayHi(); function sayHi() { console.log("Hi"); } 👉 Works because functions are fully stored in memory before execution 🎯 So what is Hoisting REALLY? It’s NOT “moving code to the top” ❌ It’s the result of how JavaScript allocates memory inside the Execution Context before execution begins ✅ 💼 Interview Insight: Most people say: 👉 “JS moves variables to top” ❌ Better answer: 👉 “Hoisting is a JavaScript behavior that occurs during the creation phase of the execution context, where memory is allocated for variables and functions before code execution. Variables declared with var are initialized as undefined, while let and const remain uninitialized in the Temporal Dead Zone, and function declarations are stored with their full definition.” #JavaScript #FrontendDeveloper #WebDevelopment #CodingJourney

⚡ Day 7 — JavaScript Event Loop (Explained Simply) Ever wondered how JavaScript handles async tasks while being single-threaded? 🤔 That’s where the Event Loop comes in. --- 🧠 What is the Event Loop? 👉 The Event Loop manages execution of code, async tasks, and callbacks. --- 🔄 How it works: 1. Call Stack → Executes synchronous code 2. Web APIs → Handle async tasks (setTimeout, fetch, etc.) 3. Callback Queue / Microtask Queue → Stores callbacks 4. Event Loop → Moves tasks to the stack when it’s empty --- 🔍 Example: console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); Promise.resolve().then(() => { console.log("Promise"); }); console.log("End"); --- 📌 Output: Start End Promise Timeout --- 🧠 Why? 👉 Microtasks (Promises) run before macrotasks (setTimeout) --- 🔥 One-line takeaway: 👉 “Event Loop decides what runs next in async JavaScript.” --- If you're learning async JS, understanding this will change how you debug forever. #JavaScript #EventLoop #WebDevelopment #Frontend #100DaysOfCode 🚀

🚀 Day 10 of My JavaScript Journey ✨Today I explored how JavaScript actually works behind the scenes — and honestly, it changed the way I look at code completely 🤯 Here’s what I learned 👇 🧠 How JavaScript Code RunsJavaScript doesn’t just execute line by line — it first creates an Execution Context which manages everything. ⚙️ Execution Context Phases1️⃣ Memory Allocation Phase Variables get stored with undefined Functions are stored completely 2️⃣ Execution Phase Code runs line by line Values get assigned and functions execute 📦 Call Stack & Execution Flow JavaScript uses a Call Stack to manage function calls Each function creates its own execution context Stack follows LIFO (Last In, First Out) 💾 Stack vs Heap Memory Stack → Stores primitive values (fast ⚡) Heap → Stores objects (reference-based 🧩) 🤖 Interpreter BehaviorJavaScript reads and executes code step by step using an interpreter — not compiled like some other languages. ❓ Why undefined Appears?Because during memory phase, variables are declared but not initialized yet. ⬆️ Hoisting Explained var is hoisted with undefined Functions are fully hoisted let & const are hoisted but stay in Temporal Dead Zone (TDZ) ❌ 🚫 Temporal Dead Zone (TDZ)You can’t access let & const variables before initialization — it throws an error. ⚠️ Function Expressions vs Hoisting Function declarations → hoisted ✅ Function expressions → behave like variables ❌ 💡 Key TakeawayUnderstanding execution context, memory, and hoisting makes debugging WAY easier and helps write cleaner code 🔥 📌 Slowly moving from writing code → to understanding how it actually works inside #JavaScript #WebDevelopment #MERNStack #CodingJourney #LearnToCode #FrontendDevelopment #DeveloperLife

Most JavaScript developers think they understand equality… until this happens: {} === {} // false And suddenly… nothing makes sense. Let me show you what’s REALLY happening 👇 In JavaScript, not all data is equal. 👉 Primitives (numbers, strings…) are stored by value 👉 Objects are stored by reference (in memory) So when you compare objects, you're NOT comparing their content… You're comparing their addresses. Now here’s where things get interesting 🔥 JavaScript doesn’t just compare values… It actually transforms them behind the scenes using something called: 👉 Type Coercion Example: "5" - 1 // 4 Why? Because JS silently converts "5" → number. But what about objects? 🤔 const obj = { id: 105 }; +obj // NaN ❌ JavaScript doesn’t know how to convert it. Except… sometimes it DOES 😳 const t1 = new Date(); const t2 = new Date(); t2 - t1 // works ✅ Wait… how did that happen?! This is where things go from “JavaScript” to magic 🧠✨ Behind the scenes, JS uses: 👉 Symbol.toPrimitive A hidden mechanism that tells the engine: “Hey, if you need to convert this object… here’s how to do it.” And here’s the crazy part 👇 You can control it yourself. const user = { [Symbol.toPrimitive](hint) { return 105; } }; +user // 105 ✅ This is called: 👉 Metaprogramming You’re not just writing code… You’re controlling how the language itself behaves. 💡 Why this matters? Because: You avoid weird bugs You understand how JS REALLY works You level up from “writing code” → “engineering behavior” And now you understand why tools like TypeScript exist… 👉 To protect you from all this hidden complexity. 🚀 Final thought: Most developers try to avoid JavaScript quirks… But the best developers? They understand them… and take control. #JavaScript #Frontend #WebDevelopment #Programming #SoftwareEngineering #TypeScript #CleanCode #100DaysOfCode #MERNStack #CodingTips #LearnToCode

Just published a new blog on JavaScript Execution Context, Hoisting, TDZ, and Call Stack. While learning these concepts, I realized how important it is to understand how JavaScript actually executes code behind the scenes. It helps explain a lot of behaviors that otherwise feel confusing. In this blog, I’ve tried to break down these concepts simply and clearly. If you’re learning JavaScript or revisiting the fundamentals, feel free to check it out: https://lnkd.in/d6S5HGPy Open to feedback and suggestions. #JavaScript #LearningInPublic #WebDevelopment #BuildInPublic #ChaiCode #Hoisting

Understanding Currying in JavaScript Ever heard of currying? It's a cool technique that makes your code cleaner and more reusable! What is Currying? Currying is when you break down a function that takes multiple arguments into a series of functions that each take one argument. Simple Example: Instead of: javascript function add(a, b, c) { return a + b + c; } add(1, 2, 3); // Output: 6 You write: javascript function add(a) { return function(b) { return function(c) { return a + b + c; } } } add(1)(2)(3); // Output: 6 Why Use It? Reusability: Create specialized functions easily Cleaner code: Break complex logic into smaller pieces Function composition: Combine functions in powerful ways Real-world benefit: javascript const addFive = add(5); addFive(2)(3); // Output: 10 Now you have a function that always adds 5 first! #javascript #webDeveloper #uiDeveloper #frontendDeveloper #react #reactjs

I ran a small JavaScript experiment today, and it was a good reminder that performance often hides inside simple concepts. I used the same function twice with the same inputs. The first call took noticeable time. The second call returned almost instantly. Nothing changed in the inputs. Nothing changed in the output. The only difference was that the second time, JavaScript didn’t need to do the work again. That’s the beauty of memoization. Instead of recalculating, it remembers the previous result and returns it from cache. What looks like a small optimization in code can make a big difference in how efficiently an application behaves. The deeper I go into JavaScript, the more I realize: the real power is not just in writing code — it’s in understanding how to make code smarter. #JavaScript #WebDevelopment #FrontendDevelopment #Memoization #Closures

The day JavaScript finally clicked wasn't when I wrote more code. It was when I understood how it *thinks*. Most beginners start at the surface: → Click → do something → Call API → get data That works. Until it doesn't. Here's what changed when I went deeper 👇 Events aren't just triggers — they're journeys A click doesn't just fire. It travels — bubbling up from child to parent, or capturing down from parent to child. Once I understood delegation and the event object, I stopped fighting the DOM and started working with it. JavaScript doesn't wait — it schedules setTimeout, setInterval, and their clear functions aren't workarounds. They're JavaScript managing time deliberately. It's not pausing — it's prioritizing. Async isn't complexity — it's design Callbacks → Promises → async/await → Fetch API. Each step wasn't a new concept. It was the same concept, refined. JavaScript isn't slow. It's non-blocking by architecture. --- The real shift wasn't technical. It was mental. From "why isn't this working?" To "I know exactly why this behaves this way." That's the difference between writing code and understanding it. What concept recently changed how you think about JavaScript? 👇 #JavaScript #WebDevelopment #AsyncJS #Frontend #CodingJourney

🚀 How JavaScript Works Behind the Scenes We use JavaScript every day… But have you ever thought about what actually happens when your code runs? 🤔 Let’s understand it in a simple way 👇 --- 💡 Step 1: JavaScript needs an Engine JavaScript doesn’t run on its own. It runs inside a JavaScript engine like V8 (Chrome / Node.js). 👉 Engine reads → understands → executes your code --- 💡 Step 2: Two Important Things When your code runs, JavaScript uses: 👉 Memory Heap → stores variables & functions 👉 Call Stack → executes code line by line --- 💡 Step 3: What happens internally? let name = "Aman"; function greet() { console.log("Hello " + name); } greet(); Behind the scenes: - "name" stored in Memory Heap - "greet()" stored in Memory Heap - function call goes to Call Stack - executes → removed from stack --- 💡 Step 4: Single Threaded Meaning JavaScript can do only one task at a time 👉 One Call Stack 👉 One execution at a time --- ❓ But then… how does async work? (setTimeout, API calls, promises?) 👉 That’s handled by the runtime (browser / Node.js) More on this in next post 👀 --- 💡 Why this matters? Because this is the base of: - Call Stack - Execution Context - Closures - Async JS --- 👨💻 Starting a series to revisit JavaScript from basics → advanced with focus on real understanding Follow along if you want to master JS 🚀 #JavaScript #JavaScriptFoundation #WebDevelopment #FrontendDevelopment #Coding #SoftwareEngineer #Tech

Things I wish someone had drawn out for me when I was starting with JavaScript. A lot of engineers write JS for years without really knowing what happens after they hit run. How does the code actually execute? What's the JS engine doing? Why does async code behave the way it does? Why does setTimeout sometimes feel unpredictable? It all makes sense once you see the full picture. Here's what these notes cover: The JS Runtime Environment — engine, call stack, memory heap, and how execution contexts are created and destroyed. The Event Loop, how it continuously monitors the call stack and decides what runs next. Callback Queue vs Microtask Queue, why Promises behave differently from setTimeout, and why microtasks always go first. JIT Compilation, how V8 interprets and optimises your code on the fly. Web APIs and the Browser, where setTimeout, DOM APIs, fetch, and localStorage actually live. Once this clicked for me, a lot of "weird" JavaScript behaviour stopped feeling weird. If you're learning JS right now, save this. Come back to it when async starts feeling confusing. What part of JavaScript took you the longest to truly understand? #JavaScript #WebDevelopment #Frontend #LearnToCode