Day 2: The Secret Life of a Function Call — Global vs. Local Execution Context 🚀 Today, I went deeper into the "Big Box" of JavaScript to understand exactly what happens when we call a function. Using this simple square function as an example, here is the line-by-line magic: 🎭 The Two-Phase Performance Phase 1: Memory Allocation Before a single line of code runs, JavaScript scans everything. n, square2, and square4 are allocated memory and set to undefined. The square function gets its own memory space with the entire function code stored inside. Phase 2: Code Execution Line 1: n is assigned the value 2. Line 6: This is where it gets interesting! A Function Invocation happens. 📦 The "Mini Box": Functional Execution Context When square(n) is called, a New Execution Context is created inside the Global one! Memory Phase: A local variable ans is created (undefined). Code Phase: num becomes 2, ans becomes 4. The Return Statement: This is the exit signal. It returns the value 4 to square2 and destroys the local execution context immediately. 📚 The Call Stack: The Manager of it All How does JS keep track of these nested boxes? The Call Stack. It's a stack (LIFO - Last In, First Out). Bottom of stack: Global Execution Context (GEC). When a function is called, it's pushed onto the stack. When it returns, it's popped off. 💡 Interview Tip: Did you know the Call Stack has many names? It’s also called the Execution Context Stack, Program Stack, Control Stack, Runtime Stack, or Machine Stack. Understanding how the stack grows and shrinks is the key to mastering Recursion and avoiding the dreaded "Stack Overflow"! Drop a "🚀" if you’re also following the Namaste JavaScript series! #JavaScript #WebDevelopment #CallStack #ExecutionContext #ProgrammingLogic #FrontendEngineer #CodingCommunity #JSFundamentals
JavaScript Function Call Execution and Call Stack Explained
More Relevant Posts
-
🚀 Dynamic Currying in JavaScript — Why it actually matters At first, currying feels like a trick: sum(1)(2)(3) But the real power isn’t syntax — it’s reusability. 💡 The idea 👉 Fix some arguments now 👉 Reuse the function later 🔧 Example const filter = fn => arr => arr.filter(fn); const filterEven = filter(x => x % 2 === 0); filterEven([1,2,3,4]); // [2,4] Instead of repeating logic everywhere, you create reusable building blocks. ⚡ Real-world uses API helpers → request(baseUrl)(endpoint) Logging → logger("ERROR")(msg) Event handlers → handleClick(id)(event) Validation → minLength(8)(value) 🧠 Key takeaway Currying isn’t about fancy functions. It’s about writing code that is: ✔ Reusable ✔ Composable ✔ Cleaner Libraries like Lodash and Ramda use this pattern heavily. Once this clicks, your approach to writing functions changes completely. #JavaScript #WebDevelopment #FunctionalProgramming #Currying #CleanCode #Frontend #Coding #100DaysOfCode #DeveloperJourney #TechCommunity
To view or add a comment, sign in
-
-
🤔 Ever wondered… Why this works: console.log(a) // undefined var a = 10; But this crashes: console.log(b) // ReferenceError let b = 20; Even though both are declared later? 👉 This is where most developers think they understand JavaScript… but they don’t. 🚀 Let’s break it down: Hoisting & Temporal Dead Zone (TDZ) 🧠 Hoisting (What actually happens behind the scenes) JavaScript doesn’t execute your code line by line directly. Before execution, it runs a Memory Creation Phase where: • Variables & functions are registered in memory • Declarations are processed first 👉 This is what we call hoisting 📦 Variable Hoisting With var: • Declaration is hoisted • Initialized with undefined So: • You can access it before declaration • But you won’t get the actual value , since Initialized with undefined in memory creation phase 💡 Key insight: Hoisting ≠ moving code It’s about how memory is allocated internally. ⚠️ let & const → Temporal Dead Zone (TDZ) Yes — let and const are also hoisted. But… They stay in a Temporal Dead Zone from: 👉 start of scope → until declaration line Accessing them early = 💥 ReferenceError 💡 Takeaway: TDZ exists to prevent unpredictable bugs caused by premature access. 👑 Function Hoisting (VIP behavior) Function Declarations are fully hoisted: ✔ You can call them before declaration But Function Expressions behave differently: • var → undefined • let/const → ReferenceError ⚡ Why this actually matters (not just theory) Understanding hoisting + TDZ helps you: • Avoid silent bugs (undefined issues) • Write predictable, cleaner code • Debug scope-related issues faster • Truly understand how JS engine works 💡 Final Thought: Most developers memorize hoisting. Good developers understand execution context. Great developers write code that doesn’t depend on hoisting at all. 📌 I’ll be sharing more deep dives like this as I learn & build in public. Follow along if you’re into JavaScript internals 🚀 #JavaScript #FrontendDevelopment #WebDevelopment #Hoisting #TDZ #LearnJavaScript #CodingTips #BuildInPublic #100DaysOfCode
To view or add a comment, sign in
-
-
🚨 JavaScript Brain Teasers That Will Mess With Your Mind. ❓ console.log(["A"] + ["B"]) 👉 Output: "AB" ❓ let arr1 = [1,2,3] let arr2 = [4,5,6] console.log(arr1 + arr2) 👉 Output: "1,2,34,5,6" ❓ console.log(+null) 👉 Output: 0 ❓ console.log(+"hello") 👉 Output: NaN ❓ let arr = [1,2,3] let str = "1,2,3" console.log(arr == str) 👉 Output: true ❓ console.log(10 == [10]) 👉 Output: true ❓ console.log(10 == [[[[10]]]]) 👉 Output: true ❓ var fruits = ["orange", "mango", "banana"] var fruitObj = { ...fruits } console.log(fruitObj) 👉 Output: {0: "orange", 1: "mango", 2: "banana"} ❓ console.log(null ?? true) 👉 Output: true ❓ console.log(undefined ?? true) 👉 Output: true 🔥 Takeaway: Most of this comes down to type coercion and how JS internally converts values. #JavaScript #WebDevelopment #Coding #Frontend #Programming #JavaScriptTips #JavaScriptTricks #JSConcepts #LearnJavaScript #FrontendDevelopment #FrontendDeveloper #WebDevCommunity #CodingTips #CodeNewbie #ProgrammingLife #DeveloperCommunity #DevLife #CodeChallenge #DailyCoding #CodeWithMe #TechContent #SoftwareDevelopment #FullStackDeveloper #JSDevelopers #ProgrammingTips #CodeDaily #DevTips
To view or add a comment, sign in
-
JavaScript is easy. Until it isn't. 😅 Every developer has been there. You're confident. Your code looks clean. You hit run. And then: " Cannot read properties of undefined (reading 'map') " The classic JavaScript wall. Here are 7 JavaScript mistakes I see developers make constantly and how to fix them: 1. Not understanding async/await ⚡ → Wrong: | const data = fetch('https://lnkd.in/dMDBzbsK'); console.log(data); // Promise {pending} | → Right: | const data = await fetch('https://lnkd.in/dMDBzbsK'); | 2. Using var instead of let/const → var is function scoped and causes weird bugs → Always use const by default. let when you need to reassign. Never var. 3. == instead of === → 0 == "0" is true in JavaScript 😱 → Always use === for comparisons. Always. 4. Mutating state directly in React → Wrong: user.name = "Shoaib" → Right: setUser({...user, name: "Shoaib"}) 5. Forgetting to handle errors in async functions → Always wrap await calls in try/catch → Silent failures are the hardest bugs to track down 6. Not cleaning up useEffect in React → Memory leaks are real → Always return a cleanup function when subscribing to events 7. Treating arrays and objects as primitives → [] === [] is false in JavaScript → Reference types don't compare like numbers — learn this early JavaScript rewards the developers who understand its quirks. 💡 Which of these caught YOU off guard when you first learned it? 👇 #JavaScript #WebDevelopment #Frontend #FullStackDeveloper #React #Programming #CodingTips #Developer #Tech #Pakistan #LearnToCode #JS #SoftwareEngineering #100DaysOfCode #PakistaniDeveloper
To view or add a comment, sign in
-
-
I did a deep dive 🔍 into JavaScript fundamentals and it reminded me why mastering the basics is non-negotiable in engineering. Here's what I explored: ▸ Variables & Hoisting — why let and const replaced var, and what the Temporal Dead Zone actually means ▸ Control Flow — from ternary operators to early return patterns that keep code clean ▸ Functions — closures, higher-order functions, and why JS treats functions as first-class citizens ▸ Arrays & Objects — the iteration methods (map, filter, reduce) every developer needs in their toolkit The more I revisit fundamentals, the more I realize how much of modern JavaScript is built on these exact concepts. Frameworks come and go — but a solid grasp of closures, scope, and data structures never goes out of style. Don't rush past the basics. They're the foundation everything else is built on. What JS concept took you the longest to truly "get"? Drop it in the comments 👇 #JavaScript #WebDevelopment #SoftwareEngineering #LearningInPublic #TechCareers
To view or add a comment, sign in
-
Most developers use JavaScript every day… But very few truly understand how it actually executes code behind the scenes. That’s where the Event Loop comes in — the heart of JavaScript’s asynchronous behavior. At a high level: JavaScript is single-threaded. But it behaves like it can handle multiple things at once. How? Because of this powerful architecture 👇 • Call Stack → Executes synchronous code line by line • Microtask Queue → Handles Promises, async/await (high priority) • Macrotask Queue → Handles setTimeout, setInterval, I/O operations • Event Loop → Constantly checks and decides what runs next Here’s the game-changing concept: 👉 Microtasks ALWAYS run before Macrotasks That’s why: Promise resolves → runs immediately after current execution setTimeout → waits even if delay is 0 This small detail is the reason behind: • Unexpected output order • Async bugs • Performance differences • UI responsiveness If you’ve ever wondered: “Why is my code running in a different order than I expected?” The answer is almost always → Event Loop behavior Understanding this doesn’t just make you a better developer — It changes how you think about writing code. You stop guessing. You start predicting. And that’s where real engineering begins. 🚀 #JavaScript #EventLoop #AsyncJavaScript #WebDevelopment #FullStackDevelopment #Programming #SoftwareEngineering #TechDeepDive #CodingJourney JavaScript Mastery w3schools.com
To view or add a comment, sign in
-
-
🧠 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗰𝗹𝗲𝗮𝗻𝗲𝗿, 𝘀𝗺𝗮𝗿𝘁𝗲𝗿 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝘄𝗶𝘁𝗵 𝗗𝗲𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗶𝗻𝗴 Destructuring is one of those features in JavaScript that can significantly improve code readability and enhances Developers Experience—yet it’s often underutilized or misunderstood. So I decided to break it down in a structured way. New Blog Published: “Mastering Destructuring in JavaScript” https://lnkd.in/gHAWq_sP 🔍 What’s covered in the blog: 🔹 Array & object destructuring fundamentals 🔹 Nested destructuring patterns 🔹 Default values cases 🔹 Practical use cases for writing cleaner, maintainable code Hitesh Choudhary Piyush Garg Akash Kadlag Suraj Kumar Jha Chai Aur Code Nikhil Rathore Jay Kadlag DEV Community #JavaScript #WebDevelopment #TechnicalWriting #CleanCode #LearningInPublic #Chaicode #Cohort
To view or add a comment, sign in
-
𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗦𝗵𝗮𝗹𝗹𝗼𝘄 𝗖𝗼𝗽𝘆 𝘃𝘀 𝗗𝗲𝗲𝗽 𝗖𝗼𝗽𝘆 📦 If you’ve ever updated state and something weird happened… this might be why 👇 🔹 Shallow Copy → copies only the first level 🔹 Nested objects are still referenced (same memory) Example: ➡️ Using { ...obj } or Object.assign() 💡 Problem: Change a nested value… and you might accidentally mutate the original object 😬 🔹 Deep Copy → copies everything (all levels) 🔹 No shared references 🔹 Safe to modify without side effects Example: ➡️ structuredClone(obj) ➡️ or libraries like lodash ⚠️ The common pitfall: You think you made a copy: ➡️ { ...user } But inside: ➡️ user.address.city is STILL linked So when you update it: ❌ You mutate the original state ❌ React may not re-render correctly ❌ Bugs appear out of nowhere 🚀 Why this matters (especially in React): State should be immutable ➡️ Always create safe copies ➡️ Avoid hidden mutations ➡️ Keep updates predictable 💡 Rule of thumb: 🔹 Flat objects? → shallow copy is fine 🔹 Nested data? → consider deep copy Understanding this difference = fewer bugs + cleaner state management And yes… almost every developer gets burned by this at least once 😄 Sources: - JavaScript Mastery - w3schools.com Follow 👨💻 Enea Zani for more #javascript #reactjs #webdevelopment #frontend #programming #coding #developers #learnjavascript #softwareengineering #100DaysOfCode
To view or add a comment, sign in
-
-
🚀 𝐃𝐚𝐲 6 – 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 (𝐒𝐢𝐦𝐩𝐥𝐞 & 𝐂𝐥𝐞𝐚𝐫) JavaScript is single-threaded… 👉 But then how does it handle things like `setTimeout`? 🤔 Let’s understand the real flow 👇 --- 💡 The Setup JavaScript uses: * Call Stack → runs code * Web APIs → handles async tasks * Callback Queue → waits for execution * Event Loop → manages everything --- 💡Example: console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); console.log("End"); --- 💡 Output: Start End Timeout --- 💡 Why? (Step-by-step) * `Start` → runs immediately * `setTimeout` → sent to Web APIs * `End` → runs immediately * Timer completes → callback goes to Queue * Event Loop checks → Stack empty * Callback pushed to Stack → executes --- ⚡ Key Insight 👉 Even with `0ms`, it does NOT run immediately 👉 It waits until the Call Stack is empty --- 💡 Simple Mental Model 👉 “Async code runs after sync code finishes” --- 💡 Why this matters? Because it explains: * execution order * async behavior * common bugs --- 👨💻 Continuing my JavaScript fundamentals series 👉 Next: **Promises (Async Made Better)** 👀 #JavaScript #WebDevelopment #FrontendDevelopment #Coding #SoftwareEngineer #Tech
To view or add a comment, sign in
-
-
𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗔𝘀𝘆𝗻𝗰/𝗔𝘄𝗮𝗶𝘁 𝗩𝗶𝘀𝘂𝗮𝗹𝗶𝘇𝗲𝗱 Confused about how async code really flows in JavaScript? Here’s a clean breakdown to make it click 👇 🔹 Promise → Starts in a pending state (⏳) 🔹 resolved → Success path (✅) → handled with .then() 🔹 rejected → Error path (❌) → handled with .catch() That’s the traditional flow — powerful, but can get messy with chaining. Now the modern way 👇 🔹 async/await simplifies everything 🔹 await pauses execution until the Promise resolves 🔹 try {} → handles success 🔹 catch {} → handles errors 💡 Same logic, cleaner syntax, easier to read Instead of chaining: ➡️ .then().catch() You write: ➡️ try { await ... } catch (error) {} Much closer to synchronous code — and way easier to debug. 🚀 Understanding this flow = writing cleaner async code + fewer bugs If you're working with APIs, interviews, or real-world apps… this is essential. 📚 𝗦𝗼𝘂𝗿𝗰𝗲𝘀: • JavaScript Mastery • w3schools.com Follow for more: Enea Zani #async #await #javascript #webdevelopment #frontend #reactjs #coding #developers #programming #100DaysOfCode #learnjavascript #softwareengineer
To view or add a comment, sign in
-
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development