Rohan kumar’s Post

Okay so nobody talks about this but teams are using Next.js routing as a state management tool and it’s quietly killing their codebases. I’ve seen it more than once. Query params holding UI state. The URL becoming the source of truth for things it was never meant to own. Filters, modal states, active tabs, all living in the router because it felt convenient at the time. And look I get it. It works. Until it doesn’t. The moment your app starts growing that approach compounds fast. Now your components are all reading from the router. Logic is scattered across pages trying to parse and sync URL state. You add one new feature and suddenly three other things break because everything is tangled up in the same query string. The router is for navigation. That’s it. Where the user is, not what the user is doing. When you start using it as a state store you’ve basically coupled your UI logic to your URL structure and now every refactor is twice as painful. Onboarding a new dev becomes a game of “figure out why this param exists and what breaks if you remove it.” Proper state management exists for a reason. Context, Zustand, Redux, whatever fits your scale. The router should be the last place your component looks for state not the first. Anyways, that’s my two cents. Have you worked in a codebase that abused the router for state? How bad did it get? #NextJS #React #Frontend #JavaScript #TechLead #WebDevelopment #SoftwareEngineering #Sydney

𝗠𝗼𝘀𝘁 𝗥𝗲𝗮𝗰𝘁 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺𝘀 𝗔𝗿𝗲 𝗣𝗿𝗲𝗱𝗶𝗰𝘁𝗮𝗯𝗹𝗲. If a React app feels slow, I usually check these first: • Is state lifted too high? • Are we passing unstable object/array props? • Are large components handling too many responsibilities? • Are expensive calculations running on every render? Before adding memoization everywhere, I try this: 1️⃣ Split large components 2️⃣ Keep state local 3️⃣ Avoid recreating objects/functions unnecessarily 4️⃣ Profile before optimizing One simple example: Instead of doing this inside render: const filteredUsers = users.filter(u => u.active); On every render… Consider whether the computation is heavy enough to memoize. Optimization is not about adding hooks. It’s about understanding cost. Most performance issues aren’t random. They’re architectural. Day 3/100 — sharing practical frontend lessons from production experience. What’s the biggest performance issue you’ve debugged in React? #ReactJS #WebPerformance #FrontendEngineering #JavaScript #SoftwareArchitecture

React is fast by default. But are YOU using it fast? Most React apps don't have a performance problem. They have a developer habit problem. Here are the advanced optimizations that separate senior devs from the rest: 1- Stop Abusing useEffect. Not everything belongs in a useEffect. Derived state? Compute it inline. Event-driven logic? Use handlers. useEffect is for synchronization, not control flow. 2- useMemo and useCallback. But only where it hurts. Wrapping everything in useMemo is not optimization, it's anxiety. Profile first. Memoize only when: A child component is wrapped in React.memo The value feeds a heavy computation It's a dependency in another hook 3- Code Splitting is Non-Negotiable Every route you don't lazy-load is bundle weight your user pays for. constDashboard=React.lazy(()=>import('./Dashboard')) Pair with <Suspense> and ship leaner initial loads. 4- Virtualize Long Lists Rendering 1,000 DOM nodes to show 10? That's a you problem. react-window or @tanstack/virtual renders only what's visible. Your scroll performance will thank you. 5- Avoid Anonymous Functions in JSX // ❌ New function reference on every render <Button onClick={()=>handleClick(id)}/> // ✅ Stable referenceconst handleItemClick =useCallback(()=>handleClick(id),[id]) React doesn't slow down. Unthoughtful patterns do. #React #Frontend #JavaScript #WebDevelopment #MERN #ReactJS #SoftwareEngineering #FrontendDevelopment

Why Next.js 16 (20x Speed 🚀) feels like a developer’s upgrade. Next.js 16 (currently in beta) is shaping up to be one of those versions where you feel the difference, not just benchmark it. Here’s a breakdown of what’s catching my eye and why it matters for teams building serious scale apps: 👇 1️⃣ Turbopack becomes default & stable The Rust-based bundler now powers Next.js 16 by default. It’s claiming 2x–5x faster production builds and up to 10x faster fast refresh loops. (If you have custom webpack setups, you still have the fallback with a flag.) 2️⃣ Built-in React Compiler support Automatic memoization is now baked in. You no longer need to sprinkle useMemo or useCallback everywhere. Note: It’s not enabled by default yet, as the build cost is still nontrivial for some apps. 3️⃣ Smarter Caching APIs & Refresh Logic New capabilities like revalidateTag() enhancements and updateTag() are giving finer control over what content needs fresh data. No more "all or nothing" caching. 4️⃣ Navigation & Routing Optimizations Incremental prefetching, layout deduplication, and smarter path reuse are part of a navigation refresh. The performance gains are real — less redundant data downloads, smoother transitions. 5️⃣ Breaking changes (but with direction) Minimum Node.js version jumps, some legacy APIs deprecated (e.g. old caching flags), and AMP is being removed. It’s a reset, in service of a simpler, leaner future platform. Question for you: If you were upgrading tomorrow, which Next.js 16 feature would you enable first? 🔹 Turbopack for the raw speed? 🔹 React Compiler for cleaner code? 🔹 Refined caching for better UX? Or maybe you’d hold off for more stability? I’d love to hear your thoughts on risk, reward, and what you’d prioritize in your app stack. 👇 #Nextjs #WebPerformance #FrontendEngineering #ReactJS #DeveloperExperience #TechLeadership

Advanced Next.js Performance Optimization (That Most Devs Ignore) If your Next.js app isn’t insanely fast, you’re leaving traffic and money on the table. Most developers stop at basic optimization. Senior engineers go deeper. Here’s how to actually optimize a Next.js app 👇 1. Use the App Router Strategically Server Components by default = less JS shipped to the client. Only use "use client" when absolutely necessary. 2. Optimize Bundle Size Run: ANALYZE=true next build Remove heavy libraries. Use dynamic imports: dynamic(() => import('./HeavyComponent')) 3. Streaming + Suspense Stream slow components instead of blocking the whole page. 4. Cache Like a Pro Use: fetch(url, { next: { revalidate: 60 } }) Control caching per request not globally. 5. Edge Runtime for Faster TTFB Move lightweight logic to the Edge for lower latency. 6. Image & Font Optimization Use next/image + next/font Avoid layout shifts. 7. Measure What Actually Matters Focus on: ✔ LCP ✔ CLS ✔ TTFB ✔ INP Use Lighthouse + Web Vitals. Advanced Rule: Performance is architecture not a plugin. If you optimize after building, you're already late. Comment “PERFORMANCE” and I’ll share my Next.js optimization checklist. #nextjs #webperformance #frontend #reactjs #javascript #softwareengineering

Passing props through 4 levels of components is not a scalability problem. It's a design problem. If you have this: ``` <App> <Dashboard user={user}> <Sidebar user={user}> <UserAvatar user={user} /> </Sidebar> </Dashboard> </App> ``` Context is your friend: ```js const UserContext = createContext(null); function App() { return ( <UserContext.Provider value={user}> <Dashboard /> </UserContext.Provider> ); } function UserAvatar() { const user = useContext(UserContext); return <img src={user.avatar} />; } ``` One important caveat: Context re-renders every consumer when the value changes. For high-frequency updates, use Zustand or Redux instead. Use the right tool for the right job. #ReactJS #JavaScript #Frontend #WebDevelopment

useMemo. useCallback. React.memo. Developers treat these as features. They're not. They're workarounds. Every state change in React triggers a full component re-render. The entire function re-executes. A new Virtual DOM tree is produced. A diffing algorithm compares old vs new. Patches are computed and applied. You're paying the cost of diffing an entire tree just to update a single text node. Memoization can prune branches, but it introduces its own overhead - dependency comparison, cognitive complexity, and it's entirely opt-in. You have to manually identify what to memoize. Miss one spot and your "optimized" app is back to re-rendering everything. What if the framework just... didn't re-render? In Granular, components execute once. When a reactive value changes, only the specific DOM node bound to that value updates. Nothing else runs. Nothing else is compared. No memoization needed. No optimization hooks. No mental model of "which renders can I skip." Full explanation: https://lnkd.in/dtQqp9YW #javascript #frontend #react #webdev #performance

React Logical Reasoning Challenge (useEffect) Predict the output of this code: import { useState, useEffect } from "react"; export default function App() { const [count, setCount] = useState(0);  useEffect(() => { console.log("Effect 1:", count);  setCount(count + 1);  }, []);  useEffect(() => { console.log("Effect 2:", count);  }, [count]); return <h1>{count}</h1>; } Questions: 1 What will be printed in console? 2 What will be shown in UI? 3 How many times will component re-render? Most developers answer this wrong on first try. Drop your answers 👇 #React #JavaScript #Frontend #ReactJS #CodingChallenge

Performance Optimization — A Quick Reality Check Performance optimization is not about using every optimization technique available. It’s about: Measuring before fixing Reducing unnecessary re-renders Avoiding premature optimization Understanding how your code actually executes In frontend apps, most performance issues come from: Unnecessary renders Heavy computations Large bundles Poor async handling Remember: Clean code is good. Predictable code is better. Measured & optimized code is best. Performance is not a hack — it’s a design decision. ⚡ #Performance #FrontendDevelopment #ReactJS #WebDevelopment #JavaScript

Why does useEffect run twice in React 18? 🤔 - If you’re seeing your API calls execute twice in development, don’t panic. - In React 18, when using StrictMode, React intentionally mounts, unmounts, and re-mounts components to detect side effects and missing cleanup logic. - This happens only in development — not in production builds. - React is stress-testing your components to ensure they are future-ready for concurrent rendering. Key takeaway: - If your useEffect runs twice, your app isn’t broken — React is helping you catch potential bugs early. Development Mode (StrictMode ON) 1️⃣ Mount Component    ↓ 2️⃣ Run useEffect    ↓ 3️⃣ Cleanup useEffect    ↓ 4️⃣ Re-Mount Component    ↓ 5️⃣ Run useEffect Again Coding: useEffect(() => {  console.log("Effect ran");  return () => {   console.log("Cleanup ran");  }; }, []); output Effect ran Cleanup ran Effect ran #ReactJS #Hooks #FrontendDevelopment #JavaScript #WebDevelopment