Understanding the Event Loop for JavaScript Developers

What Runs First in React? (Rendering vs useEffect vs useCallback vs useMemo) One day I wrote this small React code just to test my understanding: import { useEffect, useCallback, useMemo } from "react"; export default function App() { useEffect(() => { console.log("useEffect"); }, []); const increment = useCallback(() => { console.log("useCallback"); }, []); const squaredCount = useMemo(() => { console.log("useMemo"); }, []); return ( <div> {console.log("Rendering JSX")} </div> ); } And I asked myself: 👉 What runs first? At first, I guessed randomly. But then I stopped thinking like a coder… and started thinking like React. 🧠 Step 1: React always renders first React’s first job is simple: Build the UI. So this runs first: Rendering JSX Because React must render before doing anything else. 🧠 Step 2: During rendering While React is rendering: • useMemo runs immediately (it calculates something) • useCallback does NOT execute — it only stores the function So you’ll see: useMemo✅ But not: useCallback❌ That function only runs if we call increment() manually. That was my “aha” moment 💡 🧠 Step 3: After rendering → useEffect runs Once the UI is painted, React runs: useEffect Because useEffect always runs after render. ✅ Final Order (on first mount) 1️⃣ Rendering JSX 2️⃣ useMemo 3️⃣ useEffect (useCallback only runs if called) 💡 The lesson I learned Don’t just learn hooks. Learn when they run. Understanding execution order made debugging 10x easier for me. Now whenever something feels “weird” in React, I ask one question: 👉 Is this running during render or after render? Still learning React in human language. 🚀 #JavaScript #FrontendDevelopment #LearningInPublic #CleanCode #ReactJS #useEffect #useMemo #useCallback #FrontendDevelopment #LearningInPublic #JavaScript #WebDevelopment #DeveloperJourney #ReactHook

𝗥𝗲𝗮𝗰𝘁 𝗝𝗦 𝗶𝘀𝗻’𝘁 “𝗷𝘂𝘀𝘁 𝗮 𝗨𝗜 𝗹𝗶𝗯𝗿𝗮𝗿𝘆.” 𝗜𝘁’𝘀 𝗮 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗲𝗻𝗴𝗶𝗻𝗲 𝗾𝘂𝗶𝗲𝘁𝗹𝘆 𝘄𝗼𝗿𝗸𝗶𝗻𝗴 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗵𝗲 𝘀𝗰𝗲𝗻𝗲𝘀. Most developers say: 👉 “React is fast because of Virtual DOM” But that’s only 𝗵𝗮𝗹𝗳 𝘁𝗵𝗲 𝘁𝗿𝘂𝘁𝗵. The real hero is 𝗙𝗶𝗯𝗲𝗿 ⚡ 🔹 𝗪𝗵𝗮𝘁 𝗥𝗲𝗮𝗰𝘁 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗗𝗼𝗲𝘀 Instead of telling the browser 𝗵𝗼𝘄 to update the UI, React asks you one simple question: “𝗪𝗵𝗮𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝘁𝗵𝗲 𝗨𝗜 𝗹𝗼𝗼𝗸 𝗹𝗶𝗸𝗲?” React then converts your UI into 𝗲𝗹𝗲𝗺𝗲𝗻𝘁 𝘁𝗿𝗲𝗲𝘀 (plain JavaScript objects) and figures out the 𝘀𝗺𝗮𝗿𝘁𝗲𝘀𝘁 𝗽𝗼𝘀𝘀𝗶𝗯𝗹𝗲 𝘄𝗮𝘆 to update the real DOM. 🔹 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻: 𝗧𝗵𝗲 𝗠𝗶𝗻𝗶𝗺𝗮𝗹 𝗨𝗽𝗱𝗮𝘁𝗲 𝗥𝘂𝗹𝗲 Whenever state changes: React compares 𝗢𝗹𝗱 𝗧𝗿𝗲𝗲 𝘃𝘀 𝗡𝗲𝘄 𝗧𝗿𝗲𝗲 Calculates the 𝘀𝗺𝗮𝗹𝗹𝗲𝘀𝘁 𝗽𝗼𝘀𝘀𝗶𝗯𝗹𝗲 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 Updates only what’s needed in the real DOM No unnecessary re-renders. No chaos. 🔹 𝗙𝗶𝗯𝗲𝗿: 𝗧𝗵𝗲 𝗚𝗮𝗺𝗲 𝗖𝗵𝗮𝗻𝗴𝗲𝗿 🧠 Fiber makes React 𝗶𝗻𝘁𝗲𝗿𝗿𝘂𝗽𝘁𝗶𝗯𝗹𝗲. That means React can: ⏸ Pause heavy rendering ▶ Resume when the browser is free ❌ Abort low-priority work 🚨 Prioritize animations & user interactions All within a 𝟭𝟲𝗺𝘀 frame budget to keep the UI buttery smooth. 🔹 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗠𝗮𝘁𝘁𝗲𝗿𝘀 (𝗥𝗲𝗮𝗹 𝗪𝗼𝗿𝗹𝗱) Thanks to Fiber + Concurrent Rendering:  • Large apps don’t freeze  • Animations stay smooth  • User experience feels instant  • React scales insanely well This is why 𝗥𝗲𝗮𝗰𝘁 𝗽𝗼𝘄𝗲𝗿𝘀 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗮𝗽𝗽𝘀 𝗮𝘁 𝘀𝗰𝗮𝗹𝗲. If you’re learning React or working with MERN, understanding this 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝗵𝗼𝘄 𝘆𝗼𝘂 𝘄𝗿𝗶𝘁𝗲 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 𝗳𝗼𝗿𝗲𝘃𝗲𝗿. 📌 Save this. 💬 Comment “FIBER” if you want a deep-dive post next. #ReactJS #WebDevelopment #MERNStack #JavaScript #FrontendDevelopment #SoftwareEngineering #ReactDevelopers #CodingLife #TechExplained #LearnToCode #DevCommunity

Ever clicked a button on a webpage and noticed everything else still works smoothly — animations continue, inputs respond, timers fire — even though some heavy operation is happening in the background? That seamless experience is powered by the 𝗘𝘃𝗲𝗻𝘁 𝗟𝗼𝗼𝗽 in JavaScript. JavaScript is single-threaded, which means it can execute only one piece of code at a time. Yet modern applications handle API calls, timers, user interactions, and animations concurrently. The secret behind this apparent multitasking is the Event Loop. At its core, the Event Loop coordinates three major components: • The 𝗖𝗮𝗹𝗹 𝗦𝘁𝗮𝗰𝗸 – where synchronous code executes • The 𝗪𝗲𝗯 𝗔𝗣𝗜𝘀 / 𝗕𝗿𝗼𝘄𝘀𝗲𝗿 𝗔𝗣𝗜𝘀 – where asynchronous tasks like `setTimeout`, DOM events, and fetch requests are handled • The 𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸 𝗤𝘂𝗲𝘂𝗲 (𝗧𝗮𝘀𝗸 𝗤𝘂𝗲𝘂𝗲 & 𝗠𝗶𝗰𝗿𝗼𝘁𝗮𝘀𝗸 𝗤𝘂𝗲𝘂𝗲) – where completed async tasks wait to be executed Here’s how it works: When synchronous code runs, it goes directly into the call stack. If an asynchronous function like `setTimeout()` or `fetch()` is encountered, it’s handed off to the browser APIs. Once completed, its callback is pushed into a queue. The Event Loop constantly checks: Is the call stack empty? If yes, it moves queued callbacks into the stack for execution. Microtasks (like Promises) are prioritized over macrotasks (like setTimeout), which is why Promise callbacks run before timer callbacks — even if the timer delay is zero. This priority model ensures predictable execution order. Why is this needed? Without the Event Loop, JavaScript would block entirely during long-running tasks. No UI updates. No responsiveness. No scalability for interactive applications. The Event Loop enables non-blocking behavior while keeping JavaScript simple and single-threaded. Key use cases include: • Handling API requests without freezing the UI • Managing timers and intervals • Processing user events (clicks, input, scroll) • Coordinating Promise-based workflows • Powering frameworks like React and Node.js servers Understanding the Event Loop isn’t just about interviews — it’s about writing predictable, performant, and bug-free asynchronous code. Master the flow, and you master JavaScript’s true power. #JavaScript #WebDevelopment #FrontendDevelopment #SoftwareEngineering

Most React developers misunderstand useEffect. I used to be one of them. Whenever something is needed to run after the render… I would just throw it inside useEffect. It worked. But I didn’t really understand why. So I spent the last 2–3 days studying it properly through a small project called Workout Timer. The project itself is simple. It calculates workout duration based on: • workout type • number of sets • workout speed • break duration It also shows a live clock and can play a sound when values change. But the real goal wasn't the timer. The real goal was understanding React behavior and performance. --- While analyzing the project I started questioning everything. Not the code. But the architecture behind the code. Questions like: • Does this really need useEffect? • Is this state actually derived state? • Are my dependency arrays correct? • Could a stale closure break this callback? • Are components re-rendering unnecessarily? --- During this challenge I practiced: • auditing effect dependencies • avoiding effect-driven derived state • fixing stale closures in intervals • stabilizing props for memoized components • verifying cleanup logic for timers • measuring component renders --- One important lesson became very clear: useEffect is not a general-purpose tool. React’s rule is simple: > useEffect exists to synchronize with external systems. Things like: • timers • subscriptions • DOM interactions • browser APIs Everything else usually belongs in render logic. --- This challenge reminded me of something important about learning React. Real improvement doesn't always come from building bigger projects. Sometimes it comes from studying how React actually works under the hood. And this small challenge helped me understand that better. --- I share daily learning posts on Dev.to, while my portfolio contains weekly structured progress recaps. Learning in public. One concept at a time. --- #React #FrontendDevelopment #JavaScript #WebDevelopment #ReactJS #LearningInPublic

I just finished Frontend Masters “A Tour of JavaScript & React Patterns” and the biggest mindset shift for me was this: Most React “performance problems” are actually rendering problems. Not “React is slow”, but “I accidentally made more of the tree render than needed”. A few things I’m taking away and actively applying: ✅ Context is not a state manager It is a delivery mechanism. If the value changes often, it becomes a re-render broadcaster. That is perfect for “rarely changes” state (theme, locale, auth), risky for high frequency state. ✅ The fastest component is the one that does not re-render Before reaching for memo everywhere, I ask: Can I move state down? Can I split the provider? Can I pass a stable callback? Can I avoid creating new objects in props? ✅ Render cost is usually in the children Even small parent changes can re-render expensive lists, charts, tables. Splitting components and isolating heavy parts pays off more than micro-optimizing one hook. ✅ Patterns are about shaping render boundaries Custom hooks, compound components, provider splitting, controlled vs uncontrolled components. These are not just “clean code” choices. They decide how much UI updates when data changes. And a big one outside the component tree: ✅ Performance starts before React even runs Choosing the right rendering strategy changes the whole user experience: CSR when you need app-like interactivity and data is truly user-specific SSR when you need fast first paint plus fresh data per request SSG when content is stable and you want maximum speed ISR when you want SSG speed but still keep content reasonably fresh without rebuilding everything Simple rule I like now: Architecture is often performance in disguise, both in your component tree and in your rendering strategy. #react #nextjs #javascript #performance #frontend #webdevelopment #softwareengineering

Most students jump into React too early. Yes, I said it. They install: • React • Next.js • 10 npm packages But can’t explain how the DOM works Frontend is not about frameworks. It’s about understanding the foundation: • HTML → Structure • CSS → Layout & Design • JavaScript → Logic & Interaction If you don’t understand: • How the browser renders a page • What the event loop does • How CSS positioning really works • How state changes update the UI Then React will feel like magic. And magic breaks when something goes wrong. When I started focusing on: • Flexbox and Grid deeply • Vanilla JavaScript projects • Building small components from scratch Everything changed. Frameworks stopped being confusing. They became just tools means to an end, not the end itself. If you’re a student learning frontend right now: 1️⃣ Master JavaScript before React 2️⃣ Build 3–5 small projects without frameworks 3️⃣ Learn how APIs actually work 4️⃣ Debug without immediately searching StackOverflow Frontend isn’t about memorizing syntax. It’s about understanding how the browser thinks. And once you get that… You become dangerous (professionally speaking 😉). What frontend concept took you the longest to understand? #FrontendDevelopment #WebDevelopment #SoftwareEngineering #CodingJourney #CSStudents

Most frontend developers learn HTML, CSS, React, APIs, Hooks… But many skip the one concept that silently controls how all of it actually works. That concept is JavaScript Event Loop. At first, it feels “too theoretical.” But later, it becomes the reason behind so many real problems: • “Why is my state not updating?” • “Why is the API response coming late?” • “Why does setTimeout behave strangely?” • “Why is my UI freezing?” • “Why am I getting stale values in React?” These are not React problems. These are JavaScript execution order problems. JavaScript runs on a single thread. There is a mechanism that decides: ➡️ What runs first ➡️ What waits ➡️ What gets priority ➡️ Why async code works the way it does That mechanism is the Event Loop. Once you understand this, debugging becomes easier, React makes more sense, and async behavior stops feeling “magical” or confusing. A small example: console.log("A"); setTimeout(() => console.log("B"), 0); Promise.resolve().then(() => console.log("C")); console.log("D"); The output is: A D C B This simple output explains how JavaScript schedules tasks behind the scenes. The day you understand the Event Loop deeply, you stop being someone who “uses React” and start becoming someone who truly understands how frontend works. Sometimes, the most important concepts are the ones we tend to ignore. #FrontendDevelopment #JavaScript #WebDevelopment #Learning #Programming

Here’s how you can build clean, reusable components by leveraging styled-components in React One common challenge many frontend developers face is managing UI components as projects grow. At the beginning, everything feels simple. But over time, you start to see problems like: Too many duplicated buttons Inconsistent styles Hard-to-maintain CSS files Rewriting the same components again and again This is where reusable components + styled-components become very powerful. Recently, I implemented a reusable Button system where: I created a BaseButton Extended it into GoogleSignInButton and InvertedButton Used a helper function to dynamically select the right button based on props With this approach, I only pass a buttonType, and the correct styled button is rendered automatically. Example from my implementation: const getButton = (buttonType) => ({ base: BaseButton, google: GoogleSignInButton, inverted: InvertedButton, }[buttonType]); This allows me to reuse one Button component across the entire application while keeping the styles organized and consistent. Benefits of this approach: Cleaner codebase Better scalability Consistent UI Easier maintenance Faster development Instead of building new buttons every time, I now focus more on functionality and user experience. Still learning, building, and improving every day. Would love to hear how You handle component reusability in Your projects. #ReactJS #FrontendDevelopment #StyledComponents #JavaScript #WebDev #TechGrowth

Today I focused on improving my understanding of: ⚡ React component structure ⚡ Reusable UI patterns ⚡ Proper folder organization in large projects ⚡ Clean Tailwind styling without messy class overload One small improvement I made: Instead of writing repetitive UI code, I created reusable components and passed props dynamically. It made my code cleaner and easier to scale. Learning this made me realize: Good frontend development is not about making it work — it's about making it maintainable. Building consistently. Improving daily. 💻🔥 #ReactJS #FrontendDeveloper #JavaScript #TailwindCSS #WebDevelopment #LearningInPublic #SheryiansCodingSchool #FullstackDevelopment

🚀 Just shipped something I'm really pleased to — Vivid Tasks, a full-featured task management app built with zero frameworks. Pure HTML, CSS & Vanilla JavaScript. No React. No Vue. No npm install. Just clean, intentional code. ⚡ Here's what's packed inside: ✅ Task creation with priority levels, due dates & categories ⏱️ Per-task time tracking with a drift-resistant timer 🔀 Drag & drop reordering (native HTML5 API) 📊 Live dashboard — active tasks, overdue count, completion rate 🔍 Real-time search with debounced input 💾 localStorage persistence — no backend needed 📱 Fully responsive from mobile to desktop ⌨️ Keyboard shortcuts (N to create, Esc to close) 🔔 Toast notification system What I learned building this: → You don't always need a framework. Vanilla JS with a clean class-based architecture can handle surprisingly complex state. → Drift-resistant timers matter — using wall-clock time instead of counting setInterval ticks keeps tracking accurate. → CSS custom properties + a solid design token system make responsive UI a joy to build. The whole app is a single VividTasks class managing filters, sort modes, drag state, timers, and DOM rendering. Building it framework-free forced me to really understand what frameworks are actually doing under the hood. 🔗 Live Demo: https://lnkd.in/dNR-hbrv 💻 GitHub: https://lnkd.in/dyv2v9V9 Would love your feedback — drop a comment or connect if you're into frontend dev! 👇 #WebDevelopment #JavaScript #Frontend #HTML #CSS #VanillaJS #ProjectShowcase #OpenToWork