Understanding JavaScript Closures and Scope

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

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

𝗧𝗵𝗲 𝗝𝗮 v𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗘𝗫𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗖𝗼𝗻𝘁𝗲𝗫𝘁 You write code and hit "run". But what happens next? The JavaScript engine creates an Execution Context. This is the environment where your code runs. It holds variables, functions, and the scope chain. Think of it as a container that stores everything your code needs. The engine pre-scans your code before running it. It allocates memory, sets variables to undefined, and maps out the scope chain. Then it runs your code line by line. Here's an example: ``` is not allowed, so let's describe it: You have a variable devName and two functions: startSprint and displayTask. When startSprint is called, it creates a new context. When displayTask is called, it creates another context. The Call Stack is like a to-do list. It's a last-in, first-out structure. When a function finishes, its context is removed from the stack. Understanding the Execution Context helps you debug your code. It explains how closures work and how to improve performance. You can think of the Global Context like the main branch of your repo. Function contexts are like feature branches or sandboxes. The Execution Context is the key to understanding JavaScript. It's the "why" behind many weird behaviors. Once you understand it, debugging becomes easier. Source: https://lnkd.in/ghTAE-4q

Today I learned something that completely changed how I think about JavaScript function arguments. For a long time, I believed: Primitive values → Pass by value Objects/Arrays → Pass by reference But here’s the interesting part: In JavaScript, everything is passed by value. Yes — even objects. When we pass an object into a function, we are not passing the actual object. We pass a copy of the reference (memory address). So technically: Primitive → Copy of value Non-primitive → Copy of reference That small difference explains why: -Changing a primitive inside a function doesn’t affect the original. -Modifying properties of an object does affect the original. -Reassigning the object itself does NOT affect the original. Understanding this cleared up so many confusing bugs for me. Golden Rule: If you mutate → original changes If you reassign → original does not change Sometimes growth in coding isn’t about learning something new —it’s about correcting what you thought you already knew. #JavaScript #WebDevelopment #Learning #FrontendDeveloper #Functions

🗓️ 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

🚀 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

🚀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

Today I explored one of the most confusing but fascinating concepts in JavaScript — The Event Loop. JavaScript is single-threaded, but it still handles asynchronous tasks like API calls, timers, and promises smoothly. The magic behind this is the Event Loop. Here’s the simple flow: 1️⃣ Call Stack – Executes synchronous code 2️⃣ Web APIs – Handles async tasks (setTimeout, fetch, DOM events) 3️⃣ Callback Queue / Microtask Queue – Stores callbacks waiting to execute 4️⃣ Event Loop – Moves tasks to the call 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? Because Promises go to the Microtask Queue which runs before the Callback Queue. ✨ Learning this helped me finally understand how JavaScript manages async behavior without multi-threading. Tomorrow I plan to explore another interesting JavaScript concept! Devendra Dhote Ritik Rajput #javascript #webdevelopment #frontenddeveloper #100DaysOfCode #learninginpublic #codingjourney #sheryianscodingschool

🚀 Day 82 of My #100DaysOfCode Challenge Today I learned about a very useful JavaScript feature — Optional Chaining ("?."). When working with deeply nested objects, accessing properties can sometimes cause errors if a value is "undefined" or "null". Optional chaining helps solve this problem by allowing us to safely access nested properties without breaking the code. Example without Optional Chaining const user = { profile: { name: "Tejal" } }; console.log(user.profile.name); If "profile" doesn’t exist, this code would throw an error. Example with Optional Chaining const user = { profile: { name: "Tejal" } }; console.log(user?.profile?.name); Output Tejal If a property doesn't exist, JavaScript simply returns undefined instead of throwing an error. Why this is useful • Prevents runtime errors • Makes code cleaner and shorter • Helpful when working with APIs and complex objects Small modern features like this make JavaScript development much smoother. Continuing to explore deeper concepts and improving step by step. 💻✨ #Day82 #100DaysOfCode #JavaScript #OptionalChaining #WebDevelopment #LearningInPublic

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