JavaScript Variables & Hoisting Explained

🧠 Ever wondered how JavaScript keeps track of which function is running? JavaScript uses something called the Call Stack. Think of it like a stack of tasks where functions are added and removed as they execute. 🔹 How the Call Stack Works JavaScript follows a Last In, First Out (LIFO) rule. That means: The last function added to the stack is the first one to finish. Example function first() { second(); } function second() { third(); } function third() { console.log("Hello from third function"); } first(); What happens in the Call Stack 1️⃣ first() is pushed to the stack 2️⃣ second() is called → pushed to the stack 3️⃣ third() is called → pushed to the stack 4️⃣ third() finishes → removed from stack 5️⃣ second() finishes → removed 6️⃣ first() finishes → removed 🔹 Visualising the Stack Call Stack at peak: - third() - second() - first() - Global() Then it unwinds back to the Global Execution Context. 💡 Why This Matters Understanding the call stack helps you understand: - Execution order - Stack overflow errors - Debugging JavaScript - Async behaviour It’s one of the core mechanics of the JavaScript engine. Next post: The Event Loop 🚀 #JavaScript #CallStack #Frontend #WebDevelopment #LearnJS #Programming #LearningInPublic

𝗧𝗵𝗲 𝗝𝗮𝗩𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗥𝘂𝗻𝘁𝗶𝗺𝗲: 𝗙𝗶𝘅𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗠𝗲𝗻𝘁𝗮𝗹 𝗠𝗼𝗱𝗲𝗹 You may have noticed some behaviors in JavaScript that seem strange. For example: - setTimeout doesn't interrupt loops - setTimeout doesn't block - A resolved Promise still runs after synchronous code - await pauses a function but doesn't freeze the page - Rendering sometimes waits Let's explore why this happens. JavaScript executes synchronously inside a task. Nothing can interrupt that execution. Here's what we mean by 'synchronous' and 'asynchronous': - Synchronous execution: code that runs immediately, from top to bottom via the call stack - Asynchronous code: code whose result is not available immediately, it schedules something to run later Asynchronous mechanisms do not block nor interrupt the call stack. They arrange for something to run later via scheduling. Let's test this claim with a simple for loop and setTimeout: ``` is not allowed, so we use plain text instead console.log("sync start") for (let i = 0; i < 1e9; i++) {} console.log("sync end") console.log("sync start") setTimeout(() => { console.log("timeout fired") }, 0) for (let i = 0; i <

🚀 **𝐃𝐚𝐲 5 – 𝐇𝐨𝐢𝐬𝐭𝐢𝐧𝐠 𝐢𝐧 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 (𝐂𝐥𝐞𝐚𝐫 & 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐚𝐥 𝐄𝐱𝐩𝐥𝐚𝐧𝐚𝐭𝐢𝐨𝐧)** You might have seen this 👇 👉 Using a variable before declaring it But why does this work? 🤔 --- 💡 **What is Hoisting?** Hoisting means: 👉 Before execution, JavaScript **allocates memory for variables and functions** 👉 In simple words: **Declarations are processed before code runs** --- 💡 **Example:** ```js id="d5pro1" console.log(a); var a = 10; ``` 👉 Output: `undefined` --- 💡 **What actually happens behind the scenes?** Before execution (Memory Phase): * `a` → undefined Then execution starts: * `console.log(a)` → prints undefined * `a = 10` --- 💡 **Important Rule** 👉 JavaScript only hoists **declarations**, not values --- 💡 **var vs let vs const** 👉 **var** * Hoisted * initialized as `undefined` * can be accessed before declaration 👉 **let & const** * Hoisted * BUT not initialized --- ⚠️ **Temporal Dead Zone (TDZ)** This is the time between: 👉 variable declared 👉 and initialized During this: ❌ Accessing variable → **ReferenceError** --- 💡 **Example:** ```js id="d5pro2" console.log(a); let a = 10; ``` 👉 Output: **ReferenceError** --- ⚡ **Key Insight (Very Important)** 👉 Hoisting is NOT moving code 👉 It’s just **memory allocation before execution** --- 💡 **Why this matters?** Because it helps you understand: * unexpected `undefined` values * ReferenceErrors * how JavaScript actually runs code --- 👨💻 Continuing my JavaScript fundamentals series 👉 Next: **JavaScript Runtime & Event Loop** 👀 #JavaScript #WebDevelopment #FrontendDevelopment #Coding #SoftwareEngineer #Tech

⚠️ JavaScript Function Expression — A Common Corner Case That Trips Developers 🔍 The Corner Case: Hoisting Behavior console.log(add(2, 3)); // ❌ TypeError: add is not a function var add = function(a, b) { return a + b; }; 👉 Why does this fail? Because only the variable declaration (var add) is hoisted, not the function itself. So internally, JavaScript sees this as: var add; console.log(add(2, 3)); // ❌ add is undefined add = function(a, b) { return a + b; }; ✅ Now Compare with Function Declaration console.log(add(2, 3)); // ✅ 5 function add(a, b) { return a + b; } 👉 Entire function is hoisted — so it works! 💥 Another Tricky Case (Named Function Expression) const foo = function bar() { console.log(typeof bar); }; foo(); // ✅ function bar(); // ❌ ReferenceError: bar is not defined 👉 bar is only accessible inside the function, not outside! 🎯 Key Takeaways ✔ Function expressions are NOT fully hoisted ✔ Only variable declarations are hoisted (var, let, const behave differently) ✔ Named function expressions have limited scope ✔ Always define function expressions before using them #JavaScript #Frontend #CodingInterview #WebDevelopment #JSConcepts #100DaysOfCode

🚀 Understanding Factory Functions in JavaScript Ever felt confused using constructors and the new keyword? 🤔 That’s where Factory Functions make life easier! 👉 A Factory Function is simply a function that creates and returns objects. 💡 Why use Factory Functions? ✔️ No need for new keyword ✔️ Easy to understand (perfect for beginners) ✔️ Avoids this confusion ✔️ Helps in writing clean and reusable code ✔️ Supports data hiding using closures 🧠 Example: function createUser(name, age) { return { name, age, greet() { console.log("Hello " + name); } }; } const user = createUser("Sushant", 21); user.greet(); ⚠️ One downside: Methods are not shared (can use more memory) 🎯 Conclusion: Factory Functions are a great way to start writing clean and maintainable JavaScript code without complexity. #JavaScript #WebDevelopment #FrontendDeveloper #CodingJourney #LearnToCode #100DaysOfCode

Ever wondered why this prints in a different order? console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); console.log("End"); Output: Start End Timeout Wait… timeout is 0ms, right? So why does it run last? ⸻ 🧠 Welcome to the Event Loop JavaScript is single-threaded, but it handles async tasks using: 👉 Call Stack 👉 Web APIs 👉 Callback Queue 👉 Event Loop ⸻ ⚙️ What’s happening behind the scenes? 1️⃣ "Start" → goes to Call Stack → executed 2️⃣ setTimeout → sent to Web APIs 3️⃣ "End" → executed immediately 4️⃣ Callback enters queue 5️⃣ Event Loop pushes it back to stack 👉 That’s why "Timeout" runs last ⸻ 🔥 Key Insight: setTimeout(fn, 0) does NOT mean “run immediately” It means → “run after current execution is done” ⸻ 💬 Lesson learned: JavaScript isn’t just about syntax… It’s about understanding how it executes code ⸻ #JavaScript #WebDevelopment #Frontend #EventLoop #AsyncJavaScript #CodingJourney

🧠 Day 4 of 21 days challenge JavaScript Hoisting 🤯 // var → undefined // let/const → error Why different behavior? Hoisting is a JavaScript behavior where variable and function declarations are moved to the top of their scope before execution. Only declarations are hoisted, not initializations. For easy understanding :- Hoisting = moving declarations to top var is hoisted with undefined let & const are hoisted but not initialized 👉 That’s why var gives undefined but let/const give error For example :- Normal code : console.log(score); // undefined var score = 90; JS will do this internally: var score; // first reserve console.log(score); // undefined score = 90; // then assign value This changed how I understand variable behavior 🚀 #JavaScript #Hoisting #Frontend

🚨 JavaScript Gotcha: Objects as Keys?! Take a look at this 👇 const a = {}; const b = { key: 'b' }; const c = { key: 'c' }; a[b] = 123; a[c] = 456; console.log(a[b]); // ❓ 👉 What would you expect? 123 or 456? 💡 Actual Output: 456 🤯 Why does this happen? In JavaScript, object keys are always strings or symbols. So when you use an object as a key: a[b] → a["[object Object]"] a[c] → a["[object Object]"] Both b and c are converted into the same string: "[object Object]" ⚠️ That means: a[b] = 123 sets " [object Object] " → 123 a[c] = 456 overwrites it → 456 So finally: console.log(a[b]); // 456 🧠 Key Takeaways ✅ JavaScript implicitly stringifies object keys ✅ Different objects can collide into the same key ❌ Using objects as keys in plain objects is unsafe 🔥 Pro Tip If you want to use objects as keys, use a Map instead: const map = new Map(); map.set(b, 123); map.set(c, 456); console.log(map.get(b)); // 123 ✅ ✔️ Map preserves object identity ✔️ No unexpected overwrites 💬 Final Thought JavaScript often hides complexity behind simplicity. Understanding these small quirks is what separates a developer from an expert. #JavaScript #WebDevelopment #FrontendDevelopment #Programming #Coding #JavaScriptTips #JSConfusingParts #DevelopersLife #CodeNewbie #LearnToCode #SoftwareEngineering #TechTips #CodeQuality #CleanCode #100DaysOfCode #ProgrammingTips #DevCommunity #CodeChallenge #Debugging #JavaScriptDeveloper #MERNStack #FullStackDeveloper #ReactJS #NodeJS #WebDevTips #CodingLife

Early on, I used var for everything in JavaScript. Then I learned why that's a problem. JavaScript has three ways to declare variables: var — function-scoped, can be re-declared, and has hoisting quirks that cause subtle bugs. Avoid it in modern code. let — block-scoped, can be reassigned. Use it when the value needs to change. const — block-scoped, cannot be reassigned. Use it by default for everything that doesn't change. My rule of thumb: Start with const. If you need to reassign, use let. Never use var. This isn't just style preference — it's about writing predictable, debuggable code. When I open a file and see const everywhere, I immediately know those values shouldn't change. It's self-documenting. In a team environment, readable and predictable code is just as important as working code. Do you still reach for var out of habit? It's worth breaking.

🔍 A small JavaScript detail that can cause unexpected bugs: Object key ordering Many developers assume object keys are always returned in insertion order, but JavaScript actually follows a specific ordering rule when you iterate over object properties (Object.keys, Object.entries, for...in). The order is: • Integer index keys → sorted in ascending order • String keys → insertion order • Symbol keys → insertion order (not included in Object.keys) This is one of the reasons why using Object as a map can sometimes lead to unexpected iteration behavior when numeric keys are involved. If key order matters, Map is usually the more predictable choice since it preserves insertion order for all key types. Small language details like this are easy to overlook, but they often explain those subtle bugs you run into during debugging. #JavaScript #SoftwareEngineering #Frontend