Mastering JavaScript Promises: Trust, States, and Handling Errors

Still Confused by 'this' Keyword In JavaScript ? Here's Your Cheat Sheet 🔥 JavaScript's this is a frequent pain point because its value depends entirely on execution context, not where you write it. In the global scope, this refers to the window object (browser). A regular function call sets this to the global object (or undefined in strict mode). When used as an object method, this points to the owning object. Arrow functions are different—they inherit this lexically from their surrounding scope, making them ideal for callbacks. Constructors (called with new) bind this to the new instance. Event listeners set this to the target element. Use .call(), .apply(), or .bind() for explicit control. Remember: "How is the function called?" is the only question that matters. #webdev #javascript #coding #programming #this #js #frontend #developer #tech #webdevelopment #softwareengineering #codenewbie #100DaysOfCode

🏹 The Truth About "this" in Arrow Functions: If you’ve ever written an arrow function and been surprised that "this" came back as undefined, you aren't alone. It’s one of the most common areas of confusion in modern JavaScript. To understand why it happens, we have to start with the basics. 1. What is the "this" keyword? At its simplest, "this" is a reference to an object. It tells JavaScript which object is currently executing the code. However, "this" is not a fixed value. It is decided by how and where a function is created and called. 2. "this" in Normal Functions (Dynamic) In a regular function, "this" is determined at runtime. It only cares about who called the function. The Rule: "Who is to the left of the dot?" If user.getName() is called, "this" is the user. If the function is called alone, this defaults to the global window. 3. "this" in Arrow Functions (Lexical) Arrow functions are different. They do not have their own this. Instead, they inherit it from the surrounding code where they were defined. The Rule: They "borrow" the context from their parent. This makes them perfect for things like "setTimeout", where you don't want to lose the original object context. 4. The Golden Rule: "Am I inside a function?" To never get confused again, stop looking at the object curly braces {} and start looking for the parent function. Remember: Objects do NOT create scope. Only functions do. When you see an arrow function, ask yourself: 👉 “Am I inside another function?” ❌ IF NO : Then the arrow is sitting directly inside an object literal, it is in the Global Scope. "this" = Window. ✅ IF YES : Then it will borrow the this from that parent function. Does this simple "Am I inside a function?" check help you understand arrow functions better? Let’s talk in the comments! 👇 #JavaScript #WebDevelopment #Programming #JSFundamentals #SoftwareEngineering #Frontend

💡 One concept that completely changed the way I understand JavaScript: The Event Loop At some point, almost every frontend developer writes code like this: console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); Promise.resolve().then(() => { console.log("Promise"); }); console.log("End"); Many people expect the output to be: Start Timeout Promise End But the real output is actually: Start End Promise Timeout And this is where the JavaScript Event Loop becomes really interesting. ⚙️ JavaScript is single-threaded, which means it can only execute one thing at a time. But at the same time, it handles asynchronous operations like timers, API calls, and promises very smoothly. How does it do that? Through a system built around three main parts: 📌 Call Stack – where synchronous code runs. 📌 Microtask Queue – where promises are placed. 📌 Task Queue (Macrotasks) – where things like setTimeout go. The simplified flow looks like this: 1️⃣ JavaScript executes everything in the Call Stack first. 2️⃣ Then it processes Microtasks (Promises). 3️⃣ Only after that it handles Macrotasks like setTimeout. So even if setTimeout has a delay of 0, it still waits until the stack is empty and microtasks are finished. This small detail explains many things developers experience like: 🔹 "Why did my setTimeout run later than expected?" 🔹 "Why do Promises resolve before timers?" 🔹 "Why does async code sometimes behave strangely?" Once you truly understand the Event Loop, debugging asynchronous JavaScript becomes much easier. For me, it was one of those moments where a confusing behavior suddenly made perfect sense. 🤯 Curious to hear from other developers: ❓ When did the Event Loop finally “click” for you? #javascript #frontend #webdevelopment #programming #softwareengineering #eventloop #asyncjavascript #coding #developers #frontenddeveloper

Stop Shipping "Ghost Code" 👻 – Meet Knip! Is your codebase becoming a graveyard for unused files and "just in case" exports? 🏚️ As projects grow, we often leave behind dead code: exports that aren't imported anywhere, dependencies that are no longer used, and files that are just taking up space. This doesn't just look messy— hurts your bundle size, slows down CI/CD pipelines, and confuses new developers. Enter Knip ✂️ – the ultimate "dust-buster" for your JavaScript and TypeScript projects. What does Knip actually find? ✅ Unused Files: Clean up those orphaned .ts or .js files. ✅ Unused Dependencies: Identify packages in package.json that are just sitting there. ✅ Unused Exports: Find functions/types you exported but never actually used. ✅ Duplicate Exports: Spot redundant code before it becomes a headache. Why I’m a fan: Unlike many other tools, Knip is incredibly smart. It understands monorepos, supports major frameworks (React, Next.js, Svelte, etc.), and integrates seamlessly with your existing tools like ESLint and Prettier. How to get started in 10 seconds: To install: `npm install knip` To check: `npx knip` That’s it. No complex configuration is needed to get your first report. A clean codebase isn’t just about aesthetics; it’s about performance and maintainability. If you haven't audited your project recently, give Knip a try today! Have you used Knip before? What’s the biggest "dead code" monster you’ve uncovered? Let me know in the comments! 👇 #WebDevelopment #TypeScript #JavaScript #CleanCode #OpenSource #SoftwareEngineering #WebPerf #Knip Thanks to Lars Kappert

𝐉𝐚𝐯𝐚 𝐝𝐞𝐯𝐬: "𝐈 𝐡𝐚𝐯𝐞 𝟓 𝐞𝐥𝐞𝐠𝐚𝐧𝐭 𝐦𝐞𝐭𝐡𝐨𝐝𝐬 𝐰𝐢𝐭𝐡 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐧𝐚𝐦𝐞." 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐝𝐞𝐯𝐬: "𝐈 𝐡𝐚𝐯𝐞 𝟏 𝐦𝐞𝐭𝐡𝐨𝐝 𝐚𝐧𝐝 𝐚 𝐭𝐞𝐫𝐫𝐢𝐟𝐲𝐢𝐧𝐠 𝐰𝐚𝐥𝐥 𝐨𝐟 𝐢𝐟-𝐬𝐭𝐚𝐭𝐞𝐦𝐞𝐧𝐭𝐬." 🧱 Let's talk about Overriding vs. Overloading, and how JavaScript handles (or completely ignores) them. 🥊 𝐌𝐞𝐭𝐡𝐨𝐝 𝐎𝐯𝐞𝐫𝐫𝐢𝐝𝐢𝐧𝐠 (𝐓𝐡𝐞 𝐂𝐡𝐢𝐥𝐝 𝐑𝐞𝐛𝐞𝐥𝐥𝐢𝐨𝐧) This is when a child class inherits from a parent but decides it knows better. You redefine the exact same method with the exact same name. 𝑇ℎ𝑒 𝑅𝑒𝑎𝑙𝑖𝑡𝑦: It’s great until you realize you actually needed the parent's original logic too, so you awkwardly sprinkle in a `super.doSomething()` at the last second to avoid breaking the entire application. 🤹 𝐌𝐞𝐭𝐡𝐨𝐝 𝐎𝐯𝐞𝐫𝐥𝐨𝐚𝐝𝐢𝐧𝐠 (𝐓𝐡𝐞 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐈𝐥𝐥𝐮𝐬𝐢𝐨𝐧) In strictly typed languages, you can create multiple methods with the exact same name as long as they take different parameters. 𝑇ℎ𝑒 𝐽𝑆 𝑅𝑒𝑎𝑙𝑖𝑡𝑦: JavaScript literally does not care. If you write two functions with the same name, the bottom one just violently overwrites the top one. 𝑇ℎ𝑒 𝑊𝑜𝑟𝑘𝑎𝑟𝑜𝑢𝑛𝑑: We have to fake it. We create one massive function, pass in `...args`, and write 15 `if/else` blocks checking the argument lengths and `typeof` just to figure out what the frontend is actually trying to send us. JavaScript doesn't give you overloading natively; it gives you trust issues and a giant switch statement. 𝐂𝐨𝐧𝐟𝐞𝐬𝐬𝐢𝐨𝐧 𝐭𝐢𝐦𝐞: 𝐖𝐡𝐚𝐭'𝐬 𝐭𝐡𝐞 𝐮𝐠𝐥𝐢𝐞𝐬𝐭 "𝐬𝐢𝐦𝐮𝐥𝐚𝐭𝐞𝐝 𝐨𝐯𝐞𝐫𝐥𝐨𝐚𝐝𝐢𝐧𝐠" 𝐟𝐮𝐧𝐜𝐭𝐢𝐨𝐧 𝐲𝐨𝐮'𝐯𝐞 𝐞𝐯𝐞𝐫 𝐡𝐚𝐝 𝐭𝐨 𝐰𝐫𝐢𝐭𝐞 𝐭𝐨 𝐦𝐚𝐤𝐞 𝐚 𝐟𝐞𝐚𝐭𝐮𝐫𝐞 𝐰𝐨𝐫𝐤? 𝐃𝐫𝐨𝐩 𝐲𝐨𝐮𝐫 𝐜𝐫𝐢𝐦𝐞𝐬 𝐢𝐧 𝐭𝐡𝐞 𝐜𝐨𝐦𝐦𝐞𝐧𝐭𝐬. 👇 #JavaScript #WebDevelopment #SoftwareEngineering #MERNStack #CodingHumor #DeveloperLife #TechTips #Frontend

🚀 JavaScript Challenge: Do you know how Closures and Event Loops work? Pop quiz for my fellow developers! 💻 Look at the code snippet below. What do you think the console will output? Is it 0, 1, 2? Or perhaps 3, 3, 3? 💡 The Explanation If you guessed 3, 3, 3, you’re right! But do you know why? This is a classic interview question that tests your understanding of Scope, Closures, and the Event Loop. Here is the breakdown: 1. Global Scope: The variable i is declared using let outside the loop. This means there is only one instance of i shared across every iteration. 2. The Event Loop: setTimeout is asynchronous. It schedules the log function to run after 100ms. By the time that 100ms passes, the for loop has already finished executing. 3. The Final Value: When the loop finishes, the value of i has been incremented to 3 (the condition that broke the loop). 4. Closure in Action: When the three scheduled log functions finally execute, they all look at that same single variable i, which is now 3 🛠️ How to fix it? If you wanted to output 0, 1, 2, the simplest fix is to move the declaration of i inside the loop head: for (let i = 0; i < 3; i++). This creates a block scope for each iteration, effectively "capturing" the value of i at that specific moment. Why this matters: Writing clean code is about more than just making it work—it's about understanding the underlying mechanics of the language to prevent memory leaks and unexpected bugs. #JavaScript #WebDevelopment #CodingChallenge #SoftwareEngineering #Frontend #TechCommunity

JavaScript events like scroll, resize, and typing can fire hundreds of times per second. If we run heavy functions on every event, the app can become slow and inefficient. Two common solutions to control this are: Debounce and Throttle Debounce Runs the function only after the event stops firing for a specific time. Example: Search input autocomplete. Throttle Runs the function at most once in a fixed time interval, even if the event keeps firing. Example: Scroll event handling. Quick difference: Debounce → waits for user inactivity Throttle → limits how often a function can run Using these techniques improves performance, user experience, and efficiency in real-world applications. Follow for more JavaScript concepts explained visually. 🚀 #javascript #webdevelopment #frontenddeveloper #coding #softwareengineering

🚨 JavaScript Closures: A Tiny Detail, A Big Source of Bugs Sometimes JavaScript doesn’t fail because code is wrong. It fails because our mental model of scope is wrong. 🧠 Closures don’t capture values. They capture references. Because var is function-scoped, every callback shares the same binding. Result? Expected: 0, 1, 2 Actual: 3, 3, 3 No errors. No warnings. Just perfectly valid — yet misleading — behavior. ✅ Two reliable fixes • Explicit scope (closure pattern) • Block scope with let (preferred) 🎯 Why this still matters Closure-related issues quietly surface in: • Async logic • Event handlers • React hooks • Deferred execution • State management patterns These bugs rarely crash. They silently produce wrong behavior. 💡 Takeaway Closures aren’t an academic concept. They’re fundamental to writing predictable JavaScript. #JavaScript #FrontendDevelopment #WebDevelopment #SoftwareEngineering #CleanCode #ReactJS #Closures

Async JavaScript — what actually matters beyond the basics. 🚀 📌 Promises have 3 states — and they're irreversible. Once settled, a Promise can never go back to pending. That's by design. 📌 .catch covers the entire chain above it. Any error thrown anywhere flows down automatically. Not just the last step. The whole chain. 📌 fetch doesn't throw on 404 or 500. It only throws on network failure. Always check res.ok explicitly — try/catch alone won't save you here. 📌 Four combinators. Four different jobs. ✅ Promise.all → all required, fail fast ✅ Promise.allSettled → independent optionals, handle each separately ✅ Promise.race → timeout enforcement ✅ Promise.any → multiple sources, first success wins 📌 Sequential awaits are a hidden performance trap. If two calls don't depend on each other — they should run in parallel. Every unnecessary sequential await is wasted time. 📌 Retrying immediately under failure makes things worse. All instances retrying at the same moment hammer a struggling API further. Exponential backoff + jitter staggers retries — giving the API room to recover. Small decisions in async code have large consequences at scale. 💡 #JavaScript #AsyncJS #WebPerformance #FrontendEngineering #PlatformEngineering