JavaScript is Single Threaded and Synchronous Language

#js #15 **This Keyword** In JavaScript, the this keyword refers to the context in which a function is executed—basically, “who is calling this function.” But unlike many other languages, this in JavaScript is dynamic (it changes depending on how the function is called, not where it’s written). 🔹 1. Global Context In the global scope: console.log(this); In browsers → window In Node.js → global (or {} in strict modules) 🔹 2. Inside an Object Method When used inside an object: const person = { name: "Alice", greet() { console.log(this.name); } }; person.greet(); // Alice 👉 this refers to the object calling the method (person). 🔹 3. Inside a Regular Function function show() { console.log(this); } show(); Non-strict mode → window Strict mode → undefined 🔹 4. Arrow Functions (Important ⚠️) Arrow functions do NOT have their own this. They inherit it from the surrounding (lexical) scope. const obj = { name: "Bob", greet: () => { console.log(this.name); } }; obj.greet(); // undefined 👉 Here, this is NOT obj, it’s from the outer scope. 🔹 5. Event Handlers button.addEventListener("click", function () { console.log(this); // the button }); 👉 this refers to the element that triggered the event 🔹 6. Constructor Functions / Classes function Person(name) { this.name = name; } const p = new Person("John"); console.log(p.name); // John 👉 this refers to the newly created object 🔹 7. Explicit Binding (call, apply, bind) You can manually set this: function greet() { console.log(this.name); } const user = { name: "Emma" }; greet.call(user); // Emma Summary: | Situation           | `this` refers to            | | ------------------- | --------------------------- | | Global scope        | Global object               | | Object method       | The object                  | | Regular function    | Global / undefined (strict) | | Arrow function      | Lexical (outer) `this`      | | Constructor (`new`) | New instance                | | Event handler       | Element triggering event    | | `call/apply/bind`   | Explicitly set value        | #Javascript #ObjectOrientedProgramming #SoftwareDevelopment

Most developers say they “understand async JavaScript.” Most… don’t. And you can tell the difference the moment performance starts breaking. At a senior level, concepts like Web Workers, Promises, async/await, and the Event Loop aren’t just “things you know” — they’re tools you intentionally design with. Here’s the reality 👇 🚨 The Event Loop isn’t magic — it’s a constraint JavaScript is single-threaded. Always has been (ignoring workers). That means: One call stack One main thread Everything competes for it So when your app “lags”… it’s not random. You blocked the main thread. Period. ⚡ Promises & async/await don’t make things faster They make things non-blocking. Big difference. await fetchData(); This doesn’t “run in background.” It just tells the event loop: “I’ll come back later, don’t block the thread.” If your function is CPU-heavy? Congrats — you’re still freezing the UI. 🧠 Microtasks vs Macrotasks Promises → Microtask queue setTimeout / setInterval → Macrotask queue Microtasks always run before the next render. Which means: You can accidentally starve the UI if you chain too many promises. Yes, your “clean async code” can kill performance. 🔥 Web Workers = actual parallelism This is where things get real. Web Workers: Run on separate threads Don’t block the main thread Communicate via message passing Perfect for: Heavy computations Data processing Large JSON parsing Complex visual calculations (think maps, charts) But here’s the catch: You lose direct access to the DOM. So design matters. 🧩 Senior mindset shift Instead of asking: 👉 “How do I write async code?” Start asking: 👉 “What should NOT run on the main thread?” That’s the real game. 💡 Rule of thumb I follow IO-bound → Promises / async-await UI updates → Keep main thread clean CPU-heavy → Offload to Web Workers Most performance issues in frontend apps aren’t about React, Vue, or frameworks. They’re about misunderstanding how JavaScript actually runs. Master the runtime → everything else becomes easier. #javascript #webdevelopment #frontend #softwareengineering #performance #async #webworkers #seniorengineer #coding

Ever tried mixing HTML inside JavaScript… and everything just broke? 🤯 Or got weird errors for something that “looks like valid HTML”? That’s where 𝗝𝗦𝗫 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 changes the game. 🚀 𝗝𝗦𝗫 𝗕𝗮𝘀𝗶𝗰𝘀 — 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗨𝗜 𝗶𝗻𝘀𝗶𝗱𝗲 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 In React, we don’t write traditional HTML. Instead, we use 𝗝𝗦𝗫 (𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗫𝗠𝗟) — a syntax that lets you write HTML-like code inside JavaScript. 👉 It makes UI code more readable and component-driven. 💡 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗝𝗦𝗫 (𝗮𝗻𝗱 𝘄𝗵𝘆 𝘂𝘀𝗲 𝗶𝘁)? JSX is a syntax extension for JavaScript used in React to describe UI. Under the hood: ◦ JSX gets converted into React.createElement() ◦ It helps React understand what UI to render 👉 Why developers love it: ◦ Cleaner and more readable UI code ◦ Combines logic + UI in one place ◦ Reduces manual DOM manipulation 🔍 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: 𝗦𝗶𝗺𝗽𝗹𝗲 𝗝𝗦𝗫 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝐺𝑟𝑒𝑒𝑡𝑖𝑛𝑔() {   𝑐𝑜𝑛𝑠𝑡 𝑛𝑎𝑚𝑒 = "𝑆ℎ𝑢𝑏ℎ𝑎𝑚"; 𝑟𝑒𝑡𝑢𝑟𝑛 (    <𝑑𝑖𝑣>     <ℎ2>𝐻𝑒𝑙𝑙𝑜, {𝑛𝑎𝑚𝑒} 👋</ℎ2>     <𝑝>𝑊𝑒𝑙𝑐𝑜𝑚𝑒 𝑡𝑜 𝑅𝑒𝑎𝑐𝑡 𝐽𝑆𝑋 𝑏𝑎𝑠𝑖𝑐𝑠!</𝑝>    </𝑑𝑖𝑣>   ); } 🧠 𝗪𝗵𝗮𝘁’𝘀 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴 𝗵𝗲𝗿𝗲? ◦ {name} → injects JavaScript inside JSX ◦ JSX looks like HTML, but it’s actually JavaScript ◦ The component returns UI that React renders to the DOM 👉 This is declarative UI — you describe what to show, not how to update it ⚠️ 𝗝𝗦𝗫 𝗥𝘂𝗹𝗲𝘀 𝗘𝘃𝗲𝗿𝘆 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗠𝘂𝘀𝘁 𝗞𝗻𝗼𝘄 1️⃣ 𝗥𝗲𝘁𝘂𝗿𝗻 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝗽𝗮𝗿𝗲𝗻𝘁 𝗲𝗹𝗲𝗺𝗲𝗻𝘁 𝑟𝑒𝑡𝑢𝑟𝑛 (   <𝑑𝑖𝑣>    <ℎ1>𝐻𝑒𝑙𝑙𝑜</ℎ1>    <𝑝>𝑊𝑜𝑟𝑙𝑑</𝑝>   </𝑑𝑖𝑣> ); 2️⃣ 𝗨𝘀𝗲 𝗰𝗹𝗮𝘀𝘀𝗡𝗮𝗺𝗲 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗰𝗹𝗮𝘀𝘀 <𝑑𝑖𝑣 𝑐𝑙𝑎𝑠𝑠𝑁𝑎𝑚𝑒="𝑐𝑜𝑛𝑡𝑎𝑖𝑛𝑒𝑟"></𝑑𝑖𝑣> 3️⃣ 𝗔𝗹𝘄𝗮𝘆𝘀 𝗰𝗹𝗼𝘀𝗲 𝘁𝗮𝗴𝘀 <𝑖𝑚𝑔 𝑠𝑟𝑐="𝑖𝑚𝑎𝑔𝑒.𝑝𝑛𝑔" /> 4️⃣ 𝗨𝘀𝗲 𝗰𝘂𝗿𝗹𝘆 𝗯𝗿𝗮𝗰𝗲𝘀 𝗳𝗼𝗿 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 <ℎ1>{2 + 2}</ℎ1> 5️⃣ 𝗜𝗻𝗹𝗶𝗻𝗲 𝘀𝘁𝘆𝗹𝗲𝘀 𝘂𝘀𝗲 𝗼𝗯𝗷𝗲𝗰𝘁𝘀 <𝑑𝑖𝑣 𝑠𝑡𝑦𝑙𝑒={{ 𝑐𝑜𝑙𝑜𝑟: "𝑏𝑙𝑢𝑒", 𝑓𝑜𝑛𝑡𝑆𝑖𝑧𝑒: "18𝑝𝑥" }}></𝑑𝑖𝑣> 🏗️ 𝗥𝗲𝗮𝗹-𝘄𝗼𝗿𝗹𝗱 𝘂𝘀𝗲 𝗰𝗮𝘀𝗲𝘀 JSX is used everywhere in React apps: ◦ Building reusable UI components ◦ Rendering dynamic data (API responses) ◦ Conditional rendering (login/logout UI) ◦ Mapping lists (products, users, posts) 📌 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀 ✔ JSX makes UI code readable and expressive ✔ It combines JavaScript logic with HTML-like syntax ✔ Following JSX rules avoids common beginner mistakes Once you get comfortable with JSX… React starts to feel natural. 💬 Do you find JSX intuitive or confusing when you first learned it? 🚀 Follow Shubham Kumar Raj for more such content. #JavaScript #WebDevelopment #Frontend #CodingTips #100DaysOfCode #codinginterview #learnjavascript #programming #interviewprep #CareerGrowth #SowftwareEngineering #OpenToWork #ReactJS #FrontendDevelopment #Coding

𝗧𝗼𝗽 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 Whether you're preparing for your next big opportunity or mentoring others, this list can be a game-changer. 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗯𝗮𝘀𝗲𝗱 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 1. Implement `Promise.all` polyfill 2. Implement `Promise.any` polyfill 3. Implement `Array.prototype.reduce` polyfill 4. Implement Lodash’s `flatten` method 5. Implement auto-retry for promises 6. Throttle promises by batching 7. Debouncing implementation 8. Throttling implementation 9. Execute N callback-based async tasks in series 10. Output prediction for tricky 10–15 JavaScript snippets 11. Object vs Map differences in JavaScript 12. Difference between `PATCH` and `PUT` 13. What is the difference between debounce and throttle? 14. How does the JavaScript Engine work? 15. What is the Event Loop and how does the Microtask Queue work? 16. Explain Virtual DOM and its comparison mechanism 17. How to control tab order in DOM (explain `tabIndex`) 18. What is Event Capturing and Bubbling 19. How to override `toString` on `String.prototype` 20. What is OAuth and how does it work? 21. How does SSO work? 22. What are REST API methods and their differences? 23. Principles of Functional Programming 24. What are microservices? 𝗥𝗲𝗮𝗰𝘁-𝗦𝗽𝗲𝗰𝗶𝗳𝗶𝗰 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 1. Why do keys matter in React and how do they improve performance? 2. Explain how `useState` works internally 3. Implement a basic version of `useState` 4. What are React Portals? How are modals mounted using them? 5. What are Error Boundaries in React? 6. How does memoization work in React? 7. SSR vs CSR with examples and use-cases 8. What is Module Federation? 9. What is Micro-Frontend Architecture? 10. Server-Side Rendering techniques to improve SEO 11. What are memory leaks in React and how to detect them? 12. How to measure performance in a React application? 13. How would you build a tool like Create React App? 14. How do you structure reusable UI components in React? Follow Mohamed Irfaan for more related content! 🤔 Having Doubts in technical journey? 🚀 DM to book 1:1 session with me #JavaScript #WebDevelopment #ReactJs #InterviewQuestions #Fundamentals #FrontendDeveloper

#js #18 **Spread and Rest Operator** Spread (...) and Rest (...) look the same in JavaScript, but they do opposite jobs depending on where you use them. 🔹 1. Spread Operator (...) 👉 Expands (unpacks) elements Used when you want to take values out of an array/object ✅ Examples 📌 Array Spread const arr1 = [1, 2, 3];const arr2 = [...arr1, 4, 5];console.log(arr2); // [1, 2, 3, 4, 5] 📌 Copy Array (Important ⚠️) const original = [1, 2, 3]; const copy = [...original]; copy.push(4); console.log(original); // [1, 2, 3] console.log(copy); // [1, 2, 3, 4] 👉 Avoids reference issues (unlike direct assignment) 📌 Merge Arrays const a = [1, 2]; const b = [3, 4]; const merged = [...a, ...b]; 📌 Object Spread const user = { name: "Navnath", age: 28 }; const updated = { ...user, city: "Nagpur" }; 📌 Function Arguments const nums = [1, 2, 3]; function sum(a, b, c) { return a + b + c;} sum(...nums); // 6 🔹 2. Rest Operator (...) 👉 Collects (packs) elements into one Used when you want to gather multiple values into a single variable ✅ Examples 📌 Function Parameters function sum(...numbers) { return numbers.reduce((acc, curr) => acc + curr, 0);} sum(1, 2, 3, 4); // 10 👉 numbers becomes an array 📌 Array Destructuring const arr = [1, 2, 3, 4]; const [first, ...rest] = arr; console.log(first); // 1 console.log(rest); // [2, 3, 4] 📌 Object Destructuring const user = { name: "Navnath", age: 28, city: "Nagpur"}; const { name, ...others } = user; console.log(name); // Navnath console.log(others); // { age: 28, city: "Nagpur" } key difference: | Feature    | Spread (`...`)   | Rest (`...`)    | | ---------- | ---------------- | --------------- | | Purpose    | Expand values    | Collect values  | | Usage side | Right side (RHS) | Left side (LHS) | | Example    | `[...arr]`       | `[a, ...rest]`  | 🧠 Easy Way to Remember Spread → “Break it” (expand) Rest → “Collect it” (gather) ⚠️ Common Mistake const obj = { a: 1, b: 2 }; const newObj = { ...obj, a: 10 }; 👉 Output: { a: 10, b: 2 } ✔️ Last value overrides previous ones #Javascript #ObjectOrientedProgramming #SoftwareDevelopment

💡Understanding Event Info in JavaScript في JavaScript، أي تفاعل بيحصل على الصفحة بيتسمى Event In JavaScript, every interaction on a webpage is called an Event لكن الأهم 👇 لما الحدث يحصل، المتصفح بيديك Object فيه تفاصيل كتير جدًا When an event happens, the browser gives you an object full of useful details وده اسمه 👇 Event Object (Event Info) --- 🧠 أهم الحاجات اللي لازم تعرفها | Key Properties: 👉 event.target العنصر اللي حصل عليه الحدث The exact element that triggered the event 👉 event.type نوع الحدث (click, keydown, ...) The type of event 👉 event.clientX / event.clientY مكان الماوس على الشاشة Mouse position on the viewport 👉 event.key الزرار اللي اتضغط (في الكيبورد) The key that was pressed --- 🛠 حاجات مهمة جدًا | Useful Methods: ✔ event.preventDefault() تمنع السلوك الطبيعي Prevents default browser behavior ✔ event.stopPropagation() توقف انتشار الحدث Stops event bubbling --- ⚡ Example: ```javascript document.addEventListener("click", function(e) { console.log(e.target); console.log(e.type); }); ``` --- 🎯 ليه الموضوع مهم؟ - تبني UI تفاعلي - تعمل Debug أسرع - تكتب كود أنضف وأذكى --- 🔥Mastering Events = Leveling Up Your Frontend Skills #JavaScript #Frontend #WebDevelopment #Programming #Coding #Developers

POST 1 — The JavaScript Event Loop Is Not What You Think ⚙️ Every JavaScript developer says they understand the event loop. Most of them don't. And that gap is exactly why async bugs are so hard to find and fix. Here's what's actually happening 👇 ───────────────────────── First — JavaScript is single-threaded. Always. One thread. One call stack. One thing running at a time. So how does it handle timers, fetch calls, and user events without freezing? It doesn't. The BROWSER does. And then it reports back. ───────────────────────── The pieces most developers mix up: The Call Stack → where your code actually runs. Functions get pushed in, executed, and popped out. This is the only place code runs. Web APIs → setTimeout, fetch, DOM events. These live OUTSIDE the JS engine — in the browser or Node runtime. They run in separate threads you never manage. The Task Queue (Macrotask Queue) → where callbacks from Web APIs wait to be picked up. setTimeout callbacks land here. The Microtask Queue → where Promise callbacks and queueMicrotask calls wait. This queue has HIGHER priority than the task queue. ───────────────────────── The loop itself: 1. Run everything currently on the call stack until it's empty 2. Drain the ENTIRE microtask queue — every single item, including new ones added during draining 3. Pick ONE task from the task queue 4. Go back to step 1 ───────────────────────── Why this produces bugs nobody expects: Promise.resolve().then() runs before setTimeout(() => {}, 0) — always. Microtasks can starve the task queue if you keep adding new ones during draining. Long synchronous code blocks EVERYTHING — no timers fire, no events respond, no UI updates. ───────────────────────── The practical rule: Never put heavy computation directly on the call stack. Break it up. Use setTimeout to yield back to the event loop. Keep microtask chains short and predictable. ───────────────────────── Did the microtask vs task queue distinction surprise you? Drop a comment below 👇 #JavaScript #WebDevelopment #FrontendDevelopment #Programming #WebPerformance

𝗧𝗼𝗽𝗶𝗰 𝟭𝟮: 𝗘𝘃𝗲𝗻𝘁 𝗟𝗼𝗼𝗽 (𝗠𝗮𝗰𝗿𝗼 𝘃𝘀 𝗠𝗶𝗰𝗿𝗼𝘁𝗮𝘀𝗸𝘀) JavaScript is single-threaded, yet it handles thousands of concurrent operations without breaking a sweat. The secret isn't raw speed; it's an incredibly strict, ruthless prioritization engine. If you don't understand the difference between a macro and a microtask, your "asynchronous" code is a ticking time bomb for UI freezes. Summary: The Event Loop is the conductor of JavaScript's concurrency model. It continuously monitors the Call Stack and the Task Queues. To manage asynchronous work, it uses two distinct queues with vastly different priorities: Macrotasks (like setTimeout, setInterval, network events) and Microtasks (like Promises and MutationObserver). Crux: The VIP Queue: Microtasks have absolute priority. The engine will not move to the next Macrotask, nor will it allow the browser to re-render the screen, until the entire Microtask queue is completely empty. The Normal Queue: Macrotasks execute one by one. After a single Macrotask finishes, the Event Loop checks the Microtask queue again. The Starvation Risk: Because Microtasks can spawn other Microtasks, a recursive Promise chain can hold the main thread hostage, permanently blocking the UI from updating. The Deep Insight (Architect's Perspective): Traffic Control and Yielding: As architects, we must visualize the Event Loop as a traffic control system where Microtasks are emergency vehicles. When you resolve a massive chain of Promises or heavy async/await logic, you are flooding the intersection with ambulances. The browser's rendering engine—the normal traffic—is forced to sit at a red light until every single emergency vehicle has cleared. We don't just use async patterns for code readability; we must actively manage thread occupancy. For heavy client-side computations, we must intentionally interleave Macrotasks (like setTimeout(..., 0)) to force our code to yield control back to the Event Loop, allowing the browser to paint frames and keeping the UI responsive. Tip: If you have to process a massive dataset on the frontend (e.g., parsing a huge JSON file or formatting thousands of rows), do not use Promise.all on the entire set at once. That floods the Microtask queue and locks the UI. Instead, "chunk" the array and process each chunk using setTimeout or requestAnimationFrame. This gives the Event Loop room to breathe and the browser a chance to render 60 frames per second between your computation chunks. Tags: #SoftwareArchitecture #JavaScript #WebPerformance #EventLoop #FrontendEngineering #CleanCode

JavaScript has two completely different systems for sharing code between files. some developers use both without knowing which one they're using - or why it is necessary to know.  Every JavaScript file you've ever written that shares code with another file, uses a module system. Some developers use them daily without truly understanding what separates one from the other. Though the gap is small. The consequences of it are not. Modules are a way to break your code into separate, reusable pieces rather than writing everything in one enormous file. It makes the code clean, organised and maintainable. There are two main systems for doing this in JavaScript. And they are not the same. CommonJS: - Uses require() to bring in modules and uses module.exports to send them - It loads modules synchronously (blocks execution) - It is mostly used in older Node.js environments Example: -> Exporting module.exports = { greet: () => console.log("Hello") }; -> Importing const myModule = require('./myModule.js'); myModule.greet(); -> "Hello" How CommonJS loads: It loads synchronously - meaning JavaScript stops everything and waits for the module to fully load before moving on. This is Problematic for browsers. ES Modules (ESM): The current standard for browsers and modern Node.js. It is cleaner, more powerful, and built for performance. -> Named export export const greet = () => console.log("Hello"); -> Default export export default function greet() { console.log("Hello"); } -> Importing named import { greet } from './myModule.js'; -> Importing default import greet from './myModule.js'; Dynamic Imports ES Modules loads only what you need, only when you need it. When you hear "you're not splitting," this is what they mean. Instead of loading every module upfront - dynamic imports let you load a module on demand, only when it's actually needed. It results to a faster initial load times. ES Modules import() returns a Promise - so it works with .then() or async/await. It is also supported natively in ESM and available in CJS environments too. ES Modules aren't just a syntax choice. They're an architectural decision. The right system, used the right way, is the difference between an app that loads instantly and one that makes users wait. And users don't like to wait. So if you need your code base to be performant, you have your answer.

JavaScript is single-threaded. Yet it handles timers, API calls, and user clicks all at once without freezing. That confused me for a long time. Here's how it actually works. JavaScript runs on a single thread — meaning it can only do one thing at a time. One call stack, one execution. So the obvious question is: how does it handle setTimeout, fetch requests, and DOM events simultaneously without blocking everything? The answer is the runtime — and it's bigger than just JavaScript itself. When your code runs in the browser, it's not running alone. The browser gives JavaScript access to Web APIs — things like setTimeout, fetch, and event listeners. These don't run in JavaScript's call stack. The browser handles them separately in the background. JavaScript just says "hey, do this for me" and moves on. Here's where the event loop comes in. While the browser is handling that background work, JavaScript keeps executing whatever is next in the call stack. When the background task finishes — a timer expires, a fetch returns, a user clicks something — the result doesn't jump straight back into the call stack. It goes into a queue and waits. The event loop has one job: watch the call stack, and the moment it's empty, take the first item from the queue and push it in. That's the entire mechanism. Loop, check, push. Over and over. There are actually two queues worth knowing. The microtask queue — where Promises live — has higher priority. It gets fully emptied before the event loop touches the macrotask queue, where setTimeout and setInterval callbacks wait. That's why a resolved Promise always runs before a setTimeout with zero delay, even though they both feel "instant." So when you write async JavaScript, you're not really running things in parallel. You're scheduling work, trusting the runtime to hold it, and letting the event loop bring it back at the right moment. JavaScript doesn't multitask. It just knows exactly when to pause, delegate, and come back.