JavaScript Call Stack: Execution Order and Error Handling

Day 57/100 — The JavaScript Event Loop finally made sense 🔄 For a long time I used setTimeout, Promise, and async/await… but honestly — I never truly understood why JavaScript behaves the way it does. Today I learned about the Event Loop — and everything clicked. JavaScript is single-threaded. So how does it still handle multiple tasks at once? Because of 3 things working together: 🧠 Call Stack – where code runs step by step 📬 Web APIs – timers, DOM events, fetch requests handled outside JS 📋 Callback Queue / Microtask Queue – waiting tasks And the Event Loop keeps checking: “Is the call stack empty? If yes → push the next task.” The biggest surprise for me: console.log("Start"); setTimeout(() => console.log("Timeout"), 0); Promise.resolve().then(() => console.log("Promise")); console.log("End"); Output is NOT what beginners expect: Start End Promise Timeout Because microtasks (Promises) run before macrotasks (setTimeout) 💡 Realization: JavaScript is not slow… I just didn’t understand its scheduling system. Now async code feels predictable instead of magical. Learning fundamentals is like turning chaos into logic. #100DaysOfCode #JavaScript #EventLoop #AsyncJS #WebDevelopment #LearningInPublic

Why JavaScript doesn't crash when you call a function before defining it. 🧠 I recently dove deep into the "Execution Context" of JavaScript, and the concept of Hoisting finally clicked. If you’ve ever wondered why this code works: greet(); function greet() { console.log("Hello LinkedIn!"); } ...the answer lies in how the JS Engine treats your code before it even runs a single line. The Two-Phase Secret: Memory Creation Phase: Before the "Thread of Execution" starts, JavaScript scans your code and allocates memory for variables and functions. Functions are stored in their entirety in the Variable Environment. Variables (var) are stored as undefined. Code Execution Phase: Now, the engine runs the code line-by-line. Because the function is already sitting in the memory component, calling it on line 1 is no problem! The Key Takeaway: Hoisting isn't "moving code to the top" (that’s a common myth). It’s actually the result of the Memory Creation Phase setting aside space for your declarations before execution starts. Understanding the "how" behind the "what" makes debugging so much easier. #JavaScript #WebDevelopment #CodingTips #Hoisting #ProgrammingConcepts

🗓️ Day 61/100 – Understanding the JavaScript Scope Chain Today I finally understood why sometimes variables work… and sometimes they suddenly don’t. The answer = Scope Chain At first I thought JavaScript just “searches everywhere” for a variable. But no — it actually follows a very specific path. JavaScript looks for variables in this order: 1️⃣ Current function scope 2️⃣ Parent function scope 3️⃣ Global scope It climbs upward step-by-step until it finds the variable. This is called the scope chain. --- Example idea: A function inside a function inside a function… The inner function can access outer variables But the outer function cannot access inner variables So access flows inside → outside Never outside → inside --- Big realization today 💡 Most bugs I faced earlier were not logic mistakes… They were scope mistakes. If you understand scope chain: • Closures make sense • Hoisting becomes clearer • Debugging becomes easier JavaScript stops feeling random — It starts feeling predictable. Slowly the language is revealing its rules, not magic. #100DaysOfCode #JavaScript #Scope #WebDevelopment #Frontend #LearningInPublic

So… why does this code NOT throw an error? 🤔 The reason is HOISTING ! console.log(a); var a = 10; 👉 JavaScript moves variable and function declarations to the top of the code before execution. This is called Hoisting. When JavaScript sees the code, it actually understands it like this 👇 var a; console.log(a); a = 10; 🤯 What’s happening here? The variable a is declared first But its value (10) is assigned later So when console.log(a) runs, a exists but has no value yet That’s why the output is: 👉 undefined 👉 NOT an error ❌ ⚠️ Important thing to remember: var is hoisted and initialized with undefined let and const are hoisted too, but NOT initialized This happens because let and const stay in the Temporal Dead Zone until they are declared. 🚀 Why hoisting matters? ✅ Helps you avoid unexpected bugs ✅ Makes your code more predictable ✅ Frequently asked in JavaScript interviews Follow BhaviDigital for beginner-friendly frontend & backend content 🚀 #JavaScript #WebDevelopment #Frontend #LearnJavaScript #CodingJourney #BhaviDigital

🚀 JavaScript Magic: Why "Undefined" is actually a Feature, not a Bug! I just had a "Wow" moment diving into the JavaScript Execution Context, and it changed how I look at my code. Ever wondered why you can console.log a variable before you even declare it, and JavaScript doesn't lose its mind? 🤯 🧠 The Secret: Two-Phase Execution When your code runs, JavaScript doesn't just start at line 1. It takes two passes: 1.Memory Creation Phase: JS scans your code and allocates space for all variables and functions. 2. Execution Phase: It runs the code line-by-line. ⚡ The var Behavior (Hoisting) If you use var, JavaScript initializes it as undefined during the memory phase. Result: You can log it early. No error, just a quiet undefined. It’s like the variable is there, but its "suit" hasn't arrived yet. 🛑 The let & const Twist (TDZ) Try the same thing with let or const, and the engine throws a ReferenceError. Why? The Temporal Dead Zone (TDZ). While let and const are also "hoisted," they aren't initialized. They stay in a "dead zone" from the start of the block until the moment the code actually hits the declaration. The Lesson: JavaScript isn't just reading your code; it's preparing for it. Understanding the Execution Context makes debugging feel like having X-ray vision. 🦸♂️ Have you ever been bitten by the Temporal Dead Zone, or do you still find yourself reaching for var out of habit? Let’s discuss! 👇 #JavaScript #WebDevelopment #CodingTips #Frontend #Programming101

🤔 Quick question: If JavaScript is so powerful, why is it single-threaded? When I first learned that JavaScript runs on a single thread, my reaction was: “Wouldn’t that make it slow?” Turns out… being single-threaded is actually a design choice, not a limitation 👇 console.log("Start"); while (true) { // imagine a heavy blocking task } console.log("End"); 💡 What’s happening here? JavaScript executes code one task at a time. A blocking operation stops everything else. No other code can run until the current task finishes. This is why JavaScript is called single-threaded. So why would JS be designed this way? - Simpler programming model (no race conditions by default) - Predictable execution order - Perfect fit for the browser (DOM is not thread-safe). Takeaway: JavaScript runs on a single thread, meaning it can do one thing at a time. Asynchronous behavior doesn’t come from multi-threading — it comes from the event loop. #JavaScript #WebDevelopment #FullStack #LearningInPublic

🤔 Quick question: If JavaScript is single-threaded, why does it feel asynchronous? When I first learned that JS runs on a single thread, this confused me a lot. How can one thread handle timers, promises, and user events? Turns out… JavaScript isn’t doing this alone 👇 console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); console.log("End"); Output: Start End Timeout 💡 What’s really happening? - JavaScript executes synchronous code first - setTimeout is offloaded to Web APIs - Once the call stack is empty, the callback is pushed back for execution - This makes JavaScript feel asynchronous, even though it’s single-threaded Takeaway - JavaScript itself is single-threaded. - Asynchronous behavior comes from the runtime environment (browser / Node.js) and the event loop, not from JS running multiple threads. #JavaScript #WebDevelopment #FullStack #LearningInPublic

🚀 Hello everyone, lets understand Scope in JavaScript:  One of the most powerful — yet often misunderstood — concepts in JavaScript is scope. It defines where your variables and functions are accessible, and mastering it can make the difference between clean, bug-free code and hours of debugging chaos. 🔑 Types of Scope in JavaScript: ▪️ Global Scope: Variables declared outside any function/block are accessible everywhere. Great for constants, but risky if overused. ▪️ Function Scope: Variables declared inside a function are only accessible within that function. This keeps logic self-contained. ▪️ Block Scope (ES6): With let and const, variables declared inside {} are limited to that block. This prevents accidental leaks into outer code. ▪️ Lexical Scope: Outer scope variables are accessible inside inner functions, but Inner scope variables are not accessible outside their block/function. 💡 Why Scope Matters? ▪️ Prevents naming conflicts ▪️ Improves readability and maintainability ▪️ Helps avoid unintended side effects ▪️ Encourages modular, reusable code 👉Always prefer let and const over var. They respect block scope and make your code more predictable. Share your thoughts on this and rectify me wherever I'm wrong. Let’s share and learn together. #JavaScript #WebDevelopment #Scope #ES6 #CodingTips #DeveloperCommunity #TechInsights

Today I explored some powerful JavaScript concepts that level up how code actually behaves behind the scenes: ✅ this keyword – Understanding how context works inside objects and functions. ✅ try...catch – Handling errors properly so programs don’t crash unexpectedly. ✅ Arrow Functions (=>) – Writing cleaner and shorter functions (and how this behaves differently inside them). ✅ setTimeout() – Running code after a delay. ✅ setInterval() – Running code repeatedly at fixed intervals. These topics helped me understand how JavaScript handles execution, timing, and errors — which are super important for real-world applications. Slowly building strong fundamentals 💻🔥 #JavaScript #WebDevelopment #LearningInPublic #100DaysOfCode #FrontendDevelopment