JavaScript Default Parameters Explained

✅ Why This Output Is NOT What Most Expect This morning’s code was: function sum(a, b, c = 10) {} console.log(sum.length); 💡 Correct Output 2 🧠 Simple Explanation (This Is the Key) In JavaScript: 👉 function.length returns the number of parameters BEFORE the first default value Let’s look at the parameters: function sum(a, b, c = 10) {} a → counted ✅ b → counted ✅ c = 10 → ❌ NOT counted So JavaScript counts only: a, b → 2 parameters That’s why: sum.length → 2 🎯 Key Takeaways (Interview Gold) function.length ≠ total parameters It counts only parameters without defaults Defaults stop the count immediately Useful for introspection & frameworks 📌 This behavior surprises many people because it’s rarely used directly. 💬 Your Turn Did you expect 2 or 3? 😄 Comment “Didn’t know this 🤯” or “Already knew 👍” #JavaScript #LearnJS #FrontendDevelopment #CodingInterview #Functions #TechWithVeera #WebDevelopment

✅ Why Changing arguments Changes the Parameter This morning’s code was: function demo(a, b) { arguments[0] = 100; console.log(a); } demo(10, 20); 💡 Correct Output 100 🧠 Simple Explanation : 🔹 Step 1: Function call demo(10, 20); a = 10 b = 20 arguments becomes: arguments = { 0: 10, 1: 20 } 🔹 Step 2: Modify arguments arguments[0] = 100; Here’s the key rule 👇 👉 In non-strict mode, parameters and arguments are linked So when you change: arguments[0] JavaScript also updates: a 🔹 Step 3: Console output console.log(a); Since a is now updated to 100, output is: 100 🎯 Key Takeaways : arguments is not an array In non-strict mode: arguments and parameters are linked Modifying arguments[index] can change parameters This does NOT happen in: strict mode arrow functions 📌 That’s why modern JavaScript prefers rest parameters: function demo(...args) {} 💬 Your Turn Did you expect 10 or 100? 😄 Comment “Tricky but clear 👍” or “Didn’t know this 🤯” #JavaScript #LearnJS #FrontendDevelopment #CodingInterview #Functions #TechWithVeera #WebDevelopment

🌙 Evening Post — Function Reference vs Function Call (Very Important!) This morning’s code was: function show() { return "Hello"; } console.log(show); console.log(show()); 💡 Correct Output : [ Function : show ] Hello (Exact formatting may vary by browser, but the meaning is the same.) 🧠 Simple Explanation : 🔹 Line 1: console.log(show); Here, we are NOT calling the function. show refers to the function itself JavaScript prints the function definition This is called a function reference So the output shows something like: [ Function : show ] 👉 You’re telling JS: “Show me the function, not run it.” 🔹 Line 2: console.log(show()); Now the function IS called. show(); // returns "Hello" So this becomes: console.log("Hello"); ✔ Output: Hello 🎯 Key Takeaways : show → function reference (no execution) show() → function execution Functions in JS are values, just like numbers or strings You can pass functions around without calling them 📌 This difference is very important in: callbacks event handlers React props higher-order functions 💬 Your Turn Did you already know this difference? 😄 Comment “Clear now ✅” or “Didn’t notice this before 🤯” #JavaScript #LearnJS #FrontendDevelopment #CodingInterview #Functions #TechWithVeera #WebDevelopment

𝗜 thought debounce and throttle were timing tricks. Turns out they’re memory problems. This week I explored debounce and throttle, and both are really about the same idea: 👉 controlling time by remembering state Debounce waits until events stop, then runs once Throttle runs at a fixed rate, no matter how noisy the events are Under the hood, it’s all about closures: storing timers remembering the last call deciding when a function is allowed to run I implemented both in vanilla JavaScript and then again in React using hooks (useRef, useEffect) to see how memory behaves across renders. Turns out: Performance isn’t about doing more — it’s about doing things at the right time. Still learning, but this clicked for me 💡 Would love to hear how others explain debounce vs throttle. #JavaScript #React #WebPerformance #LearningInPublic #Closures

🟨 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗗𝗮𝘆 𝟰𝟵: 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 (𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝘀 𝗣𝗿𝗼𝗯𝗹𝗲𝗺) In JavaScript, we often use callbacks to handle async tasks — API calls, timers, or events. But callbacks introduce a hidden issue called Inversion of Control. 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮 𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸? A callback is a function passed to another function and executed later. 𝘴𝘦𝘵𝘛𝘪𝘮𝘦𝘰𝘶𝘵(() => { 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘭𝘰𝘨("𝘑𝘢𝘷𝘢𝘚𝘤𝘳𝘪𝘱𝘵"); }, 1000); 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹? When we pass a callback, we give control of our code to another function. We don’t control: • When it runs • How many times it runs • Whether it runs at all 🔹 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 𝘢𝘱𝘪.𝘤𝘳𝘦𝘢𝘵𝘦𝘖𝘳𝘥𝘦𝘳(𝘤𝘢𝘳𝘵, 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 () { 𝘢𝘱𝘪.𝘱𝘳𝘰𝘤𝘦𝘦𝘥𝘛𝘰𝘗𝘢𝘺𝘮𝘦𝘯𝘵(); }); Here: • proceedToPayment is our code • createOrder decides when it runs • Our callback executes only when the API decides, based on its internal logic or async events. This is Inversion of Control in action. 🔹 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗜𝘀 𝗮 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 • Unexpected behavior • Harder debugging • Leads to callback hell in large apps 🔹 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 Promises and async / await keep control in our hands. 🔹 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Callbacks give control away. Promises bring it back. 💬 GitHub link in the comments for examples #JavaScript #Day49 #100DaysOfCode #Frontend

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

🤔 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

Stop Chaining, Start Awaiting! Are you still getting lost in a sea of .then() blocks? While Promises revolutionized JavaScript, async/await has taken readability to the next level. The logic is simple: Both methods do the same thing, but the debugging experience is night and day. By switching to async/await, you get: 🔸 Cleaner Flow: Your code looks synchronous and is much easier to follow. 🔸 Better Error Handling: Use standard try/catch blocks instead of multiple .catch() triggers. 🔸 Easier Debugging: You can finally step through your async logic line by line. The winner? Async/Await for better maintainability! 🏆 #JavaScript #WebDev #CodingTips #FrontendDeveloper

🤔 Quick JavaScript quiz! What do you think this logs? console.log(x); var x = 10; If you said undefined, you’re right ✅ Welcome to JavaScript hoisting. Hoisting means JS moves declarations (not values) to the top of their scope before running your code. Now try this 👇 console.log(y); let y = 10; 💥 Error! let and const are hoisted too, but live in the Temporal Dead Zone until declared. 👉 Rule of thumb: Hoisting is real, but clean, top-down code saves you from bugs. What tripped you up more when you were learning JS — var or let? 👀 #JavaScript #Frontend #WebDev #LearningInPublic

Day 42/100 – An Important JavaScript Concept Many People Ignore Not all performance issues come from bad code. Sometimes they come from too many function calls. 📌 Topic: Debouncing vs Throttling Both are used to control how often a function executes. ✅ Debouncing Runs the function only after a certain time has passed since the last event. Example use cases: • Search input • Form validation 👉 Executes when user stops typing. ✅ Throttling Runs the function at a fixed interval, no matter how many times the event occurs. Example use cases: • Scroll events • Window resize 👉 Executes every X milliseconds. Understanding these concepts helps build faster and smoother applications. Small improvements. Big impact. On to Day 43 🚀 #100DaysOfCode #JavaScript #WebDevelopment #LearningInPublic #Consistency #FrontendDevelopment