Understanding JavaScript Promises: Immutable Once Settled

Promises in JavaScript is actually an interesting concept. Promises are one of the most important concepts in modern JavaScript. A Promise is an object that represents a value that will be either available now, later or never. It has three states: pending, fulfilled and rejected. Instead of blocking the program while waiting for something like data or an image to load, a promise allows JavaScript to continue running and then react when the task finishes. We can build a promise by using the Promise constructor, which takes an executor function with two parameters: resolve and reject. Resolve is called when the operation succeeds, and reject is called when something goes wrong. We can also consume promises using the .then() to handle success and catch() to handle errors. Each .then() method returns a new promise which allows us to chain asynchronous steps in sequence. Another powerful concept is PROMISIFYING, this simply means converting old callback-based APIs (like setTimeout or certain browser APIs) into promises so they can fit into modern asynchronous workflows. Understanding how to build, chain and handle promises properly is the foundation we need in mastering asynchronous JavaScript. #JavaScript #WebDevelopment #FrontendDevelopment #TechJourney #Growth

Behind the Screen – #31 Do you know? JavaScript is #SingleThreaded, but it can still handle multiple tasks at once. How? JavaScript uses something called the #EventLoop. Here’s the idea: 👉 JavaScript runs one task at a time (single thread)   👉 Long tasks (like API calls, timers) are handled outside the main thread   👉 When they are ready, they are added to a queue   👉 The Event Loop picks tasks from the queue one by one  So instead of doing everything at once, #JavaScript manages tasks efficiently. That’s why: • Your UI doesn’t freeze during API calls   • Timers work in the background   • Apps feel responsive  🔥 JavaScript doesn’t do multiple things at the same time — it manages them smartly. #javascript #webdevelopment #frontend #softwareengineering #techfacts

🔗 What is Promise Chaining in JavaScript? When working with asynchronous operations in JavaScript, we often need to perform tasks in sequence — one after another. This is where Promise Chaining comes in. Promise chaining means attaching multiple .then() methods to a promise so that the output of one step becomes the input of the next. ✅ Why It’s Needed : Imagine: 🔹 Fetching user data 🔹 Then fetching that user’s posts 🔹 Then processing those posts Each step depends on the previous one. Promise chaining allows us to handle this flow cleanly and predictably. 👉 How It Works : Each .then(): 🔹 Waits for the previous promise to resolve 🔹 Receives its result 🔹 Returns a new promise 🔹 That returned promise is passed to the next .then() in the chain. Example: 🔹 Each step runs only after the previous one completes 🔹 Errors are handled in a single .catch() 🚀 Benefits of Promise Chaining ✔ Avoids “callback hell” ✔ Keeps asynchronous code readable ✔ Maintains clean execution flow ✔ Centralized error handling 💡 Key Insight 👉 If you return a value → it automatically becomes a resolved promise. 👉 If you return a promise → the next .then() waits for it. #JavaScript #WebDevelopment #Frontend #AsyncProgramming #Promises

Most JavaScript developers use async/await every day without actually understanding what runs it. The Event Loop is that thing. I spent two years writing JavaScript before I truly understood how the Event Loop worked. Once I did, bugs that used to take me hours to debug started making complete sense in minutes. Here is what you actually need to know: 1. JavaScript is single-threaded but not blocking The Event Loop is what makes async behavior possible without multiple threads. 2. The Call Stack runs your synchronous code first, always Anything async waits in the queue until the stack is completely empty. 3. Microtasks run before Macrotasks Promise callbacks (.then) execute before setTimeout, even if the timer is zero. This catches a lot of developers off guard. 4. Understanding this helps you write better async code You stop writing setTimeout hacks and start understanding why certain code runs out of order. 5. It explains why heavy computations block the UI A long synchronous task freezes the browser because nothing else can run until the stack clears. The mindset shift: JavaScript is not magic. It follows a very specific execution order and once you see it clearly, you write code that actually behaves the way you expect. 🧠 The Event Loop is one of those concepts that separates developers who guess from developers who know. When did the Event Loop finally click for you? 👇 If this helped, I would love to hear your experience. #JavaScript #WebDevelopment #EventLoop #Frontend #SoftwareEngineering

JavaScript is single-threaded, yet it handles asynchronous tasks effortlessly. Understanding the Event Loop finally made it make sense. JavaScript has one call stack and can only execute one task at a time. So naturally, the question becomes: how does it handle things like API calls, timers, or user clicks without freezing the entire application? The answer is the Event Loop. When we use asynchronous features like setTimeout, fetch, or event listeners, JavaScript doesn’t handle them directly. Instead, these tasks are delegated to the browser’s Web APIs. While the browser processes these operations in the background, JavaScript continues executing other code on the call stack. Once the asynchronous task finishes, its callback is placed in a queue. The Event Loop continuously checks whether the call stack is empty, and when it is, it moves the queued callback into the stack for execution. That’s how non-blocking behavior works, even though JavaScript itself runs on a single thread. Understanding this changed how I debug, structure async code, and reason about performance. If you're learning JavaScript, don’t skip the Event Loop. It’s foundational to everything from API calls to modern frameworks. #JavaScript #WebDevelopment #FrontendDevelopment #LearningInPublic #TechJourney #Growth

For the longest time, prototypes in JavaScript felt like one of those topics everyone says is “important”, but it’s not always obvious why. What helped me understand it was thinking about how JavaScript avoids repeating things. Imagine you’re creating multiple user objects in an app. Each user might need the same function, like saying hello. Instead of copying the same function inside every object, JavaScript keeps it in a shared place called the prototype. A small example makes it clearer: function Person(name) { this.name = name; } Person.prototype.sayHello = function () { console.log("Hello " + this.name); }; const user1 = new Person("Prerna"); const user2 = new Person("Alex"); Even though sayHello() isn’t written inside user1 or user2, both of them can still use it. Why? Because when JavaScript can’t find something on the object itself, it starts looking upwards. First it checks the object Then its prototype Then the prototype’s prototype …and this continues until it either finds the method or reaches null. That lookup path is what people call the prototype chain. Once I understood this, a lot of built-in JavaScript behavior started making more sense. Methods like .map(), .filter(), or .toString() aren’t magically appearing, they exist somewhere up that chain. It’s one of those concepts that feels abstract at first, but once it clicks, you start seeing it everywhere in JavaScript. #javascript #webdevelopment #frontenddevelopment #reactjs #fullstackdeveloper #devcommunity #programming

𝐉𝐚𝐯𝐚 𝐝𝐞𝐯𝐬: "𝐈 𝐡𝐚𝐯𝐞 𝟓 𝐞𝐥𝐞𝐠𝐚𝐧𝐭 𝐦𝐞𝐭𝐡𝐨𝐝𝐬 𝐰𝐢𝐭𝐡 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐧𝐚𝐦𝐞." 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐝𝐞𝐯𝐬: "𝐈 𝐡𝐚𝐯𝐞 𝟏 𝐦𝐞𝐭𝐡𝐨𝐝 𝐚𝐧𝐝 𝐚 𝐭𝐞𝐫𝐫𝐢𝐟𝐲𝐢𝐧𝐠 𝐰𝐚𝐥𝐥 𝐨𝐟 𝐢𝐟-𝐬𝐭𝐚𝐭𝐞𝐦𝐞𝐧𝐭𝐬." 🧱 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

🚀 Day 77 — Microtask Queue vs Callback Queue in JavaScript Today I learned how JavaScript prioritizes asynchronous tasks using Microtask Queue and Callback Queue. Understanding this helped me finally understand execution order in async JavaScript. 🧠 The Hidden Queues Behind Async JavaScript When asynchronous tasks finish execution, they don’t directly enter the Call Stack. Instead, they wait inside queues. ✅ Callback Queue (Macrotask Queue) Handles: setTimeout setInterval DOM events ✅ Microtask Queue Handles: Promises (.then, .catch) queueMicrotask MutationObserver --- 🔍 Example console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); Promise.resolve().then(() => { console.log("Promise"); }); console.log("End"); --- ⚙️ Output Start End Promise Timeout --- 🤯 Why This Happens? Execution order: 1️⃣ Synchronous code runs first 2️⃣ Microtask Queue executes next 3️⃣ Callback Queue executes last 👉 Microtasks always get higher priority than callbacks. --- 📌 Key Learning Even if setTimeout has 0ms delay, Promises execute before it because Microtask Queue is processed first. Understanding this explains many async bugs and unexpected outputs. --- JavaScript execution feels much clearer as I go deeper into how things work internally. --- #Day77 #JavaScript #EventLoop #AsyncJavaScript #WebDevelopment #LearningInPublic

💡 Interesting JavaScript Question I Faced Recently (2+ Years Experience Level) Recently I came across a practical JavaScript question that focused on understanding how Promises work internally. 📌 The Task Create a Promise when the JavaScript file loads. The Promise should remain in the pending state until the user clicks a button. Two buttons should determine the outcome: • Resolve button → resolves the Promise • Reject button → rejects the Promise The implementation had to be done using Vanilla JavaScript and HTML only. 🎯 Approach Create a Promise immediately when the script loads. Attach event listeners to two buttons. Call resolve() when the resolve button is clicked. Call reject() when the reject button is clicked. Handle the result using .then() and .catch(). ⚡ Key Learning This small exercise highlights the core behavior of a Promise: • A Promise starts in pending state • It transitions to resolved or rejected once • The state cannot change again after settlement Questions like these test JavaScript fundamentals and event-driven async behaviour, which are very important in frontend interviews. Curious to know - how would you extend this example? Maybe with async/await, UI feedback, or disabling buttons after resolution? #javascript #frontenddevelopment #webdevelopment #promises #learning #interviewquestions