React used to freeze your entire app just to update a list. Before React 16, the reconciler was recursive. Once it started updating, it couldn't stop. 10,000 nodes? Main thread blocked for 500ms. Animations janky. Inputs unresponsive. User thinks the app is broken. Then Fiber came. The difference: Stack Reconciler (old): → Call stack-based recursion → Can't pause mid-render → All or nothing → Big update = frozen UI Fiber: → Linked list of "work units" → Can pause after each unit → Checks if browser needs the thread back → Yields, then continues next frame Same 10,000 nodes. But now React does a little work, gives the browser a chance to paint, handles your click event, then continues rendering. This is why modern React can do: → useTransition - mark updates as low priority → useDeferredValue - let urgent updates go first → Suspense - pause rendering, show fallback → Concurrent features - multiple renders in progress None of this was possible with the recursive approach. You can't pause a call stack halfway through. Fiber isn't just a rewrite. It's a different architecture that treats rendering as interruptible work instead of a blocking function call. That's why your React 18 app feels smoother than your React 15 app ever did. #react #javascript #frontend #webdev #reactjs #programming #webdevelopment #typescript #reactfiber #performance
Albert Em’s Post
More Relevant Posts
-
🚀 I built a Random Joke Generator Web App… and learned a lot along the way! At first, working with APIs felt confusing 😅 But this project helped me finally understand how things actually work. 💡 What it does: • Generates random jokes using API • Supports multiple categories (Programming, Dark, etc.) • Text-to-speech feature 🔊 • Copy jokes instantly 📋 🧠 What I learned: • API handling (fetch, async/await) • DOM manipulation • Making UI more interactive 🔗 Live Demo:https://lnkd.in/g8yyVQp6 I’m still improving my frontend skills every day. 👉 Which feature should I add next? #WebDevelopment #Frontend #JavaScript #100DaysOfCode
To view or add a comment, sign in
-
-
🚨 React Hooks Mistake That Can Break Your App (And How to Fix It) Ever faced this error? 👇 💥 "Rendered more/fewer hooks than expected" Here’s a simple reason why it happens 👇 ❌ Wrong Approach if (condition) { return null; } useEffect(() => { // logic }, []); 👉 What actually happens: 🟢 1st render → condition = true → component exits early → useEffect NOT called 🔵 2nd render → condition = false → now useEffect IS called ⚠️ React sees: Render 1 → 0 hooks Render 2 → 1 hook 💥 Boom → error 🤔 Quick Question Why does React care so much? 👉 Because React tracks hooks by position, not by name. ✅ Correct Approach useEffect(() => { // logic }, []); if (condition) { return null; } 👉 Now every render looks like: Render 1 → useEffect Render 2 → useEffect ✔ Same order → No error 🧠 Golden Rule (remember this forever) 👉 Hooks must always run in the same order 👉 Always keep them at the TOP Think of hooks like seat numbers in a movie theatre 🎬 If someone randomly disappears from seat 2, everyone shifts — total chaos 😵 👉 Same with React hooks. 👇 Have you ever debugged this error before? #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #ReactHooks #CodingTips
To view or add a comment, sign in
-
Your React app is slow. And 90% of the time, it's one of these 6 things. 🔥 I've spent years debugging sluggish React apps. The same culprits show up every time. Here's what to fix — and in what order: ① React.memo — stop unnecessary re-renders If a child component re-renders every time the parent does, wrap it in React.memo. It's the fastest win you'll get. Start here. ② useMemo — cache expensive calculations Heavy sorting, filtering, or transforming data on every render? useMemo caches the result until dependencies change. Your CPU will thank you. ③ useCallback — stabilise your function refs Passing functions as props? Without useCallback, a new function is created on every render — breaking React.memo completely. Always pair the two together. ④ Code Splitting — stop loading what users don't need React.lazy() + Suspense = load components only when they're needed. A 200kb page becomes a 40kb page. First load feels instant. ⑤ Virtualisation — lists with 1000+ items? Don't render what the user can't see. react-window or react-virtual renders only visible rows. The difference is night and day. ⑥ Avoid Prop Drilling — restructure before you optimise Passing props through 5 layers? Every middle component re-renders unnecessarily. Lift state with Context or reach for Zustand. Clean architecture is free performance. The rule I follow: Profile first. Fix what the data shows. Never guess. Open React DevTools Profiler, record an interaction, and find your actual bottleneck — then apply the fix. Optimising the wrong thing just adds complexity. Performance isn't about using every trick. It's about using the right one. 💬 Which of these has given you the biggest performance win? Drop it below 👇 #ReactJS #Performance #Frontend #JavaScript #WebDevelopment #React #Programming #CleanCode #WebPerformance #SoftwareEngineering
To view or add a comment, sign in
-
-
Is poor state architecture the real reason your React app is hard to scale? Full guide: https://lnkd.in/d9Ayg3gM ➤ In most codebases, yes. • Props: parent-to-child only • Local State: UI & form interactions • Context API: auth, themes, no prop drilling • Redux: large-scale apps only • Hooks: performance & global state access ➤ Golden rule: keep state as local as possible. ➤ Simplicity before premature complexity. #ReactJS #FrontendDevelopment #StateManagement #Redux #JavaScript
To view or add a comment, sign in
-
-
You add useMemo. The app is still slow. Before you blame React — two questions. Skip them and memo is just noise. Without useMemo, React just runs the computation. With useMemo, on every render, it checks the dependencies, saves the result in memory, and updates the dependencies. You only benefit if the dependencies stay the same. Otherwise, you’re paying for a cache that doesn’t help. Each time you use useMemo, you’re making a bet that caching will cost less than just running the computation. Most people make this bet without actually checking. Before you add useMemo, ask yourself two questions. First question: Are the dependencies stable between renders? // ❌ object created inside — reference is always new const filters = { search: input, page: current } // ✅ object from the store — reference is stable const filters = useSelector(state => state.filters) If you create a dependency inside the component, its reference changes on every render. The cache will never be used, so memo just adds extra work. If your dependencies aren’t stable, stop. Memo won’t help. Second question: Is the computation actually expensive? You don’t have to guess. There’s a clear way to check using console.time. If it takes less than 1ms, memo isn’t needed because caching takes about as long as the computation. Over 5ms, it’s worth considering. Over 16ms, you should definitely use memo. Why 16ms? Browsers render 60 frames per second, so each frame has 16ms. If a computation takes longer, users will notice lag. This is the line between a smooth UI and a visible freeze. The mistake I see most often: a developer notices slowness, adds useMemo everywhere, DevTools shows more work being done. The lag remains. They don't understand why. Memo without measurement isn't optimization. It's superstition. Measure first. Then decide. #Frontend #JavaScript #React #Vue #WebDev #Performance #SoftwareEngineering
To view or add a comment, sign in
-
-
🚀 Leveling up your React performance game! If you're building modern apps with ⚛️ React, understanding these two hooks can seriously boost your app's efficiency: 🔹 useMemo Optimize expensive calculations by memoizing results. It only recomputes when dependencies change — saving performance and avoiding unnecessary work. 💡 Example: const result = useMemo(() => computeExpensiveValue(a, b), [a, b]); 🔹 useCallback Memoize functions to prevent unnecessary re-renders, especially when passing callbacks to child components. 💡 Example: const handleClick = useCallback(() => { // logic here }, [deps]); ✨ Pro Tip: Use them wisely — overusing these hooks can actually hurt performance instead of helping! 📌 When to use: ✔️ Heavy computations → useMemo ✔️ Stable function references → useCallback Keep your apps fast, clean, and scalable 💪 #ReactJS #WebDevelopment #Frontend #JavaScript #Programming #100DaysOfCode
To view or add a comment, sign in
-
-
🚀 **Built a Live Character Counter App** Recently, I worked on a small project — a **Live Character Counter App** — to strengthen my JavaScript fundamentals. Through this project, I practiced: * String methods like `trim()` and `replace()` * Array method `filter()` for accurate word counting * Conditional logic * DOM manipulation * Event handling (especially `input` events) The app tracks: ✔ Character count ✔ Word count ✔ Remaining characters ✔ Live input feedback This project helped me understand how to handle edge cases like extra spaces and improve user experience with real-time updates. 💡 Small projects like this build a strong foundation for real-world applications. 🔗Live preview:- https://lnkd.in/gGVaUv9G If you have any suggestions or ideas for improvement, I’d really appreciate your feedback in the comments 🙌 #JavaScript #WebDevelopment #FrontendDevelopment #CodingJourney #100DaysOfCode
To view or add a comment, sign in
-
I used to think I understood React… until I had to pass the same state through 3–4 components just to control one small thing 😅 It worked, but it didn’t feel right. So instead of jumping to another tutorial, I tried to actually "understand the problem" and that led me to the Context API. To keep things simple, I built a tiny “bulb toggle” app 💡 At first, everything was prop-based. Then I switched to Context… and the difference was obvious. Now: 1. I’m not passing props through unnecessary layers 2. Components feel more independent 3. The code is easier to read and reason about But I also learned something important while doing this: 👉 Context is helpful, but it’s not a replacement for everything If the state is simple and only needed in a few places, props are still totally fine. Context starts to make sense when multiple parts of your app need the same data. Still early in my journey, but this was one of those small moments where things started to click. If you’ve worked with Context before -> 👉 how do you decide between props, Context, or other state tools? #learninginpublic #reactjs #webdevelopment #javascript #frontenddevelopment
To view or add a comment, sign in
-
-
This is one of my recently built project, a simple Quiz App using React, and it turned out to be a great revision of core concepts. 🔹 State Management (useState) Handled multiple states like current question index and user answers. 🔹 Updating State Without Mutation Instead of pushing directly into arrays, I used: setUswerAnswer([...uswerAnswer, ans]); This reinforced why React needs immutable updates to re-render properly. 🔹 Conditional Rendering Displayed questions, score, and results based on the index: Show questions while quiz is running Show result when quiz ends This made me more comfortable with dynamic UI rendering. 🔹 Handling Lists & Events Mapped over options and attached click handlers to capture user answers. Also learned the importance of keys in lists. Quiz Link : https://lnkd.in/g_TU_Puy Still learning and improving step by step #ReactJS #JavaScript #FrontendDevelopment #LearningByBuilding
To view or add a comment, sign in
-
-
Today everything started to feel… more real. React Masterclass (Day 5). I began with: • Sharing state between components • Passing functions as props • Understanding how React handles state updates But instead of stopping there, I asked: How would this actually work in a real app? 💰 So I built a Budget Tracker: • Set initial balance • Add expenses that reduce it in real-time • Dynamic UI based on current state • Data persisted using localStorage • Clean updates using functional state 💡 Key concepts that clicked: • Lazy initialization (run logic only once) • Functional updates (state based on previous state) • Derived values (calculating remaining balance) Small concepts → Real product thinking. #React #Frontend #WebDevelopment #LearningInPublic #JavaScript
To view or add a comment, sign in
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development
If your app was entirely react and doesn't used external technologies, for said apps, nothing ever changed.