JavaScript Event Handling: Bubbling, Capturing & Delegation

🚀 From Confused to Confident in JavaScript Every developer starts with excitement. At first, JavaScript feels easy — let, const, loops, functions… all simple. Then Hoisting appears. Why is the variable undefined even before it’s assigned? Then comes Closure. How does a function remember variables even after it has finished executing? Three days gone. Still confused. And then… Async JavaScript. Nested callbacks. Callback Hell. Frustration. But quitting wasn’t an option. Promises were learned. Async/Await was understood. The console became a best friend. Small projects were built. And one day, the realization happened: JavaScript isn’t hard. Clarity just takes time. Six months later, the same developer confidently explains: Execution Context. Closure. Event Loop. Async/Await. 💡 Moral Every developer struggles. The ones who don’t stop… are the ones who grow. #MERN #JavaScript #WebDevelopment #Frontend #MERNStack #CodingJourney

🚀Day 3/100 #100DaysOfCode — JavaScript Core Foundations Today, I revised the fundamentals that actually control how JavaScript behaves under the hood. 🔹 Execution Context JavaScript runs in two phases inside the Global Execution Context: 1️⃣ Creation Phase Memory allocated var → initialized as undefined let & const → hoisted but placed in the Temporal Dead Zone (TDZ) 2️⃣ Execution Phase Code executes line by line Variables receive real values 🔹 var vs let vs const var is hoisted with undefined let & const are hoisted but inaccessible before declaration (TDZ) var allows re-declaration let & const do not var & let allow reassignment const does not var is function-scoped let & const are block-scoped 🔹 Arrow Functions Not hoisted like traditional functions No own this (inherits lexically) Cleaner implicit return const sum = (a, b) => a + b; 🔹 Rest & Spread Rest → collects remaining parameters into an array Spread → expands array elements 🔹 Destructuring Cleaner extraction from arrays & objects: let { name: myName, address: { city } } = person; Understanding execution context + scope is the foundation for closures, async JS, and advanced patterns. No shortcuts. Just depth. Day 4 tomorrow. #JavaScript #WebDev #IntermediateJS #CodingChallenge #Frontend #SoftwareEngineering #MERNStack #LearningEveryday

Day 6 of JavaScript Deep Dive 🚀 Today’s focus: Execution Context, Hoisting, and Call Stack mechanics. Most developers “use” JavaScript. Very few understand how the engine actually executes it. Key takeaways: • JavaScript runs in two phases – Creation & Execution • var is hoisted and initialized as undefined • let and const live in the Temporal Dead Zone • Functions are fully hoisted • Call Stack follows LIFO (Last In, First Out) • Shadowing can completely change output Understanding the JS execution model is what separates average frontend developers from strong engineers. On to Day 7: Event Loop & Promise Internals. Hashtags #JavaScript #FrontendDevelopment #MERNStack #WebDevelopment #FAANGPreparation #CodingJourney #SoftwareEngineering #InterviewPreparation #DaysOfCode

🚨 JavaScript Hoisting – Something Most Developers Still Misunderstand Most developers say: 👉 “JavaScript moves variables to the top of the scope.” But that’s not actually what happens. Let’s test this 👇 console.log(a); var a = 10; Output: undefined Now try this: console.log(b); let b = 20; Output: ReferenceError: Cannot access 'b' before initialization 💡 Why the difference? Both var and let are hoisted. But the real difference is initialization timing. ✔ var is hoisted and initialized with undefined during the creation phase. ✔ let and const are hoisted but stay inside the Temporal Dead Zone (TDZ) until the line where they are declared. That’s why accessing them before declaration throws an error. 👉 So technically: JavaScript doesn’t “move variables to the top”. Instead, the JavaScript engine allocates memory for declarations during the creation phase of the execution context. Small detail. But it explains a lot of confusing bugs. 🔥 Understanding this deeply helps when debugging closures, scope issues, and async code. #javascript #frontend #webdevelopment #reactjs #coding #softwareengineering

Early in my JavaScript journey, async code was where bugs went to hide. Everything looked fine. The API was fast. The UI worked. Yet production felt slow. At first, I blamed the backend & network. Then “JavaScript being JavaScript.”😹 Until I finally looked at the async code. I realized something important: I was using async/await and Promises interchangeably—without intention. I thought async/await was “better,” so I added await everywhere. Inside loops, mappers & places that were supposed to run in parallel. The code was readable, but quietly inefficient. Later, on another project, I did the opposite. Long .then() chains. Nested logic. Error handling scattered across files. It worked, but no one wanted to touch it. That’s when it clicked. Async/await and Promises are the same engine, just different driving styles. 👉Promises helped me see concurrency. 👉Async/await helped me reason about logic. The real problem wasn’t the tools. It was using them without understanding why. Some lessons learned the hard way: • await in a loop can kill performance • Mixing .then() and await hurts readability • Async/await is still non-blocking—your event loop matters • Clean async code scales better than clever async code Now, I choose deliberately: • Promises for orchestration and parallelism • Async/await for clarity and maintainability Async bugs don’t usually scream. They whisper until your app scales then the effects kicks in What async mistake taught you the biggest lesson in your career? #JavaScript #AsyncAwait #Promises #SoftwareEngineering #WebDevelopment #LearningInPublic

🚀 Understanding the JavaScript Event Loop (Microtasks vs Macrotasks) Consider this code: console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); Promise.resolve().then(() => { console.log("Promise"); }); console.log("End"); What’s the output? Many expect: Start Timeout Promise End But actual output is: Start End Promise Timeout Why? Because of the Event Loop. JavaScript handles tasks in two major queues: • Microtasks (Promises, queueMicrotask) • Macrotasks (setTimeout, setInterval) Execution order: 1️⃣ Synchronous code runs first 2️⃣ Microtasks run next 3️⃣ Then Macrotasks Even if setTimeout has 0ms delay, it still waits for the macrotask queue. Understanding this explains: • Why some async bugs feel “random” • Why Promises run before setTimeout • Why UI updates sometimes behave unexpectedly JavaScript isn’t single-threaded chaos. It’s single-threaded with a well-defined event model. Understanding the Event Loop changes how you debug async code. What async behavior confused you the most before learning this? #javascript #frontenddeveloper #webdevelopment #eventloop #softwareengineering

Today JavaScript humbled me again 😭 I thought I understood async JS… but then the Event Loop said “bro sit down.” We explored the chaotic squad behind the scenes: 🧵 Call Stack – the overworked intern running the code 🌀 Event Loop – the manager deciding who gets attention ⚡ Microtask Queue – the VIP lane (Promises, queueMicrotask, process.nextTick) ⏳ Macrotask Queue – the waiting room (setTimeout, setInterval, setImmediate) Biggest plot twist of the day 👇 You write: setTimeout(fn, 0) and think: “Nice… this will run immediately.” JavaScript: “Haha… no.” Because JS first clears the Call Stack, then executes Microtasks, and only then checks Macrotasks. So the real priority is: Call Stack → Microtasks → Macrotasks Which explains why JavaScript sometimes feels like it's gaslighting you during console.log outputs 💀 Huge thanks to Devendra Dhote Bhaiya for explaining this so clearly. Really fun session and lots of brain upgrades today 🧠⚡ JavaScript is basically: “Single-threaded… but emotionally multi-threaded.” #JavaScript #EventLoop #AsyncJavaScript #WebDevelopment #LearningInPublic

Most developers use JavaScript every day. Very few understand what actually happens behind the scenes. One of the most important fundamentals is this: 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐢𝐬 𝐬𝐢𝐧𝐠𝐥𝐞-𝐭𝐡𝐫𝐞𝐚𝐝𝐞𝐝. It can execute only one task at a time. Yet somehow it still handles network requests, timers, and user interactions smoothly. So what makes this possible? First, every function call enters the 𝐂𝐚𝐥𝐥 𝐒𝐭𝐚𝐜𝐤. This is where JavaScript executes code. If the stack is busy, nothing else can run. But asynchronous tasks like `setTimeout`, `fetch`, and DOM events don’t run inside the JavaScript engine itself. They are handled by 𝐁𝐫𝐨𝐰𝐬𝐞𝐫 𝐖𝐞𝐛 𝐀𝐏𝐈𝐬. Once those operations finish, their callbacks move into the 𝐂𝐚𝐥𝐥𝐛𝐚𝐜𝐤 𝐐𝐮𝐞𝐮𝐞. Then the 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 steps in. It constantly checks whether the Call Stack is empty. When it is, tasks from the queue are pushed into the stack for execution. That simple cycle is what enables asynchronous behavior—even in a single-threaded language. Understanding this mental model makes development much easier: * Debug async issues by visualizing the call stack and queue * Use `async/await` confidently once you understand promises * Avoid blocking operations that freeze the event loop Once this concept clicks, JavaScript suddenly feels far less mysterious. When did the 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 finally make sense to you? #JavaScript #WebDevelopment #FrontendEngineering #EventLoop #AsyncProgramming #SoftwareEngineering #ProgrammingFundamentals #MERNStack

🚀 JavaScript Made Simple: Hoisting & Temporal Dead Zone (TDZ) Ever wondered why JavaScript sometimes behaves… unexpectedly? 🤔 Most of the time, the answer lies in two concepts: 👉 Hoisting 👉 Temporal Dead Zone (TDZ) Let’s break them down in a simple and friendly way 👇 🔹 Hoisting (What happens before your code runs?) Before JavaScript executes your code, it quickly scans it and stores variables in memory. • var → hoisted and given a default value undefined • let & const → hoisted but NOT initialized Example: console.log(a); // undefined var a = 10; 👉 That’s why no error here—JavaScript already knows about a 🔹 Temporal Dead Zone (TDZ) Now here’s where things get interesting 👇 TDZ is the time between when a variable is in memory and when it’s actually declared. During this time: ❌ You cannot access the variable ❌ Trying to do so will throw an error Example: console.log(b); // ReferenceError let b = 20; 👉 Even though b exists, JavaScript says: “Not yet!” 🚫 🔹 Quick Difference • var → accessible before declaration (returns undefined) • let/const → NOT accessible before declaration (TDZ) 🔹 Why should you care? Because this helps you: ✔ Avoid confusing bugs ✔ Understand how JavaScript actually works ✔ Write cleaner and more predictable code 🔹 Final Thought JavaScript isn’t weird… it’s just doing things behind the scenes that we don’t always see 👀 Once you understand Hoisting and TDZ, you start thinking like a real JavaScript developer 🚀 #JavaScript #WebDevelopment #NodeJS #Frontend #Coding #Developers #Tech #Debugging