Debounce and Throttle for Performance Optimization

useDebounce vs debounce() I got this wrong for months. Working on user forms and search where, every keystroke was triggering an API call. I reached for debounce() first. Big mistake. Here’s what I learned: Wrong - debounce() in render body // Re-creates a new debounced fn on EVERY render const handleSearch = debounce((val) => fetchResults(val), 300); Better - but needs careful handling // Stable across renders, but you manage the fn ref const handleSearch = useRef( debounce((val) => fetchResults(val), 300) ).current; Cleanest - useDebounce hook const [query, setQuery] = useState(''); const debouncedQuery = useDebounce(query, 300); useEffect(() => { if (debouncedQuery) fetchResults(debouncedQuery); }, [debouncedQuery]); // fires only after user stops typing The core difference: debounce(fn) → delays a function call. Lives outside React. Needs useRef to stay stable. useDebounce(value) → delays a state value. React-native, auto-cleanup via useEffect. No ref juggling. My rule now: → Input-driven API calls? useDebounce → Click/scroll/resize handlers? debounce() inside useRef This one pattern alone cut our unnecessary API calls by ~80% on the search feature. What’s your go-to approach? Drop it below 👇 #React #ReactHooks #FrontendEngineering #JavaScript #WebPerformance #ReactDeepDive #SeniorEngineer

I shipped a React dashboard with 40+ memoized components. The profiler was embarrassing. Here's what I found. Every component was wrapped in React.memo. Every callback was in useCallback. Every derived value was in useMemo. I thought I was being a good engineer. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗳𝗶𝗹𝗲𝗿 𝘁𝗼𝗹𝗱 𝗮 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝘀𝘁𝗼𝗿𝘆: → 200+ unnecessary renders per interaction → Memory allocation spiking on every keystroke → Frames dropping below 60fps during filter operations The irony? The memoization itself was causing the slowdown. Unstable object references being passed as deps. useCallback wrapping functions that didn't need stability. React.memo on components that rendered in 0.1ms anyway. Every "optimization" was a small tax. 40 components. Multiplied. I spent a day removing memo. Performance improved immediately. The lesson I took away: 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 𝗶𝘀 𝗴𝘂𝗲𝘀𝘀𝗶𝗻𝗴. 𝗔𝗻𝗱 𝗰𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝘁 𝗴𝘂𝗲𝘀𝘀𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗱𝗮𝗻𝗴𝗲𝗿𝗼𝘂𝘀 𝗸𝗶𝗻𝗱. Profile first. Memoize second. Only what the profiler tells you to. What React "best practice" did you have to unlearn? #React #Frontend #JavaScript #WebPerformance #SoftwareEngineering

I spent 3 hours debugging a “simple” frontend issue… and it turned out to be one line. The problem? An API was getting called on every keystroke. Network tab = chaos 👀 Dozens of API calls for a single search. 👉 The issue: No debouncing. Here’s what the code looked like before: useEffect(() => { if (!query) return; fetch(`https://lnkd.in/eNE6UBeq) .then(res => res.json()) .then(data => setData(data)); }, [query]); Every keypress → API call ❌ Here’s the fix (debouncing): useEffect(() => { if (!query) return; const timer = setTimeout(() => { fetch(`https://lnkd.in/eNE6UBeq) .then(res => res.json()) .then(data => setData(data)); }, 300); return () => clearTimeout(timer); }, [query]); ✅ API calls reduced by ~70% ✅ Smoother UI ✅ Better user experience Lesson: Frontend performance isn’t just about what you render… It’s about when you trigger things. Small change. Big impact. Have you used debouncing or throttling in your apps? Where did it make the biggest difference? #frontend #reactjs #javascript #webperformance #softwareengineering

I built a JS Minifier that does more than just remove whitespace. 🛠️⚡ Most online minifiers are "black boxes." You paste code, and you get a mess back. I wanted to build something that helps developers understand how their code is being transformed. The Engineering Details: AST Debugging : Built-in visualization using acorn to inspect the Abstract Syntax Tree. Zero UI Lag : Minification runs in a Web Worker, keeping the main thread free for a 60fps experience. Modern Compatibility: Fully supports ES2024+ syntax, powered by Terser. Smart State: Persistent configuration via localStorage and a responsive UI using react-resizable-panels. Mangle & Compress: Smart variable renaming and dead-code removal. The Results: In my tests, I'm consistently seeing 40-60% size reductions in milliseconds. #JavaScript #WebDev #Performance #Frontend #VibeCoding

Most developers know map, filter and reduce exist. Fewer know when to use which one. Here is how I think about it: map() — when you need to transform every element Same number of items in, same number out. Just different shape. filter() — when you need to remove some elements Same data, fewer items. Nothing is transformed. reduce() — when you need one value from the whole array Total, average, grouped object, flat list — anything single. The real power comes from chaining them: devs  .filter(d => d.active)  .map(d => d.name)  .sort() Three operations. One clean chain. No loops. No temporary variables. And the ones people forget: find() — returns one element, not an array some() — true if at least one matches every() — true only if all match flatMap() — map + flatten in one step Save this for your next code review. Which array method do you reach for most often? #JavaScript #WebDevelopment #Frontend #CleanCode #SoftwareEngineering

5 frontend mistakes I keep seeing — and how to fix them 1️⃣ Overusing useEffect Not everything is a side effect. Derived state? Just compute it inline. → Ask yourself: "does this actually need to react to something?" If not, skip it. 2️⃣ No error boundaries One broken component taking down the whole page is not a good look. → Wrap key sections with an ErrorBoundary. Few minutes of work, saves you from a lot of headaches. 3️⃣ Fetching data directly inside components No caching, no deduplication = chaos. → Use React Query or SWR. Your network tab will thank you. 4️⃣ Giant components that do everything If you're scrolling for 5 seconds inside a single file, it's time to split. → One responsibility per component. If you can't name it easily, it's doing too much. 5️⃣ Skipping loading & empty states The happy path isn't the whole product. → Design for 0 results, slow connections, and errors from day one — not as an afterthought. Clean frontend code isn't clever. It's predictable.

Most developers use Next.js for routing and SSR. Then spend hours solving problems Next.js already solved. Here are 5 Next.js features that will give you that time back: 1. Parallel Routes Render multiple pages in the same layout simultaneously. Dashboards with independent loading states — no prop drilling, no context hacks. @slot convention. Built in. Most devs never touch it. 2. Intercepting Routes Open a modal that shows a different URL. User refreshes? Full page loads instead. Instagram-style photo expand — without building Instagram-style complexity. 3. Server Actions Write server-side functions and call them directly from components. No API route. No fetch. No endpoint to maintain. One function. Full stack. Done. 4. next/og Generate dynamic Open Graph images at the edge. Custom thumbnails for every blog post, every product, every user profile. What used to need a separate service — now lives in one file. 5. Partial Prerendering (PPR) Static shell. Dynamic content streams in. Your page loads instantly — then fills in the live data. Best of SSG and SSR in a single route. No compromise. These aren't experimental side features. They're production-ready tools sitting in your existing Next.js setup. The developers shipping fastest aren't writing more code. They're using the framework they already have — properly. Which of these are you already using — and which caught you off guard?

Let’s talk about useEffect. Not just how to use it… but how to use it properly. Because this is where a lot of frontend issues start. First thing to understand: useEffect is for side effects. That means anything outside the normal render flow: – API calls – subscriptions – timers – interacting with the DOM It’s not a general-purpose tool for logic. Where most people get it wrong: They treat useEffect like: “run this code when the component loads” And then you start seeing things like: – multiple API calls – infinite loops – unnecessary re-renders – state updating in circles A simple example: If you do this: useEffect(() => { fetchData(); }); That runs on every render. Now imagine what happens when state updates… The correct approach is to be intentional: – run once → use [] – run on change → add specific dependencies But here’s the shift that changed things for me: I stopped asking “where can I use useEffect?” And started asking “do I even need useEffect here?” Because in many cases, you don’t. Instead: – derive values directly during render – use event handlers for interactions – use tools like React Query (TanStack Query) for data fetching React Query handles: – caching – background updates – loading & error states – request deduplication So you don’t have to manually manage all of that inside useEffect. That shift alone removes a lot of bugs. useEffect is not a “run code” tool. It’s a synchronisation tool. Once you understand that… your code becomes simpler and more predictable. #React #ReactQuery #Frontend #WebDevelopment #JavaScript #SoftwareEngineering

Day 22 #100DaysOfCode 💻 1. Difference between map and filter? — B. map transforms, filter selects 2. What triggers this? (addEventListener) — B. Button click 3. What happens here? (onclick) — B. Runs on click 4. What is the output? (map without return) — B. [undefined, undefined, undefined] 5. Which is correct to get input value? — B. value 6. What is the output? (array.find) — B. 2 7. What does async/await simplify? — B. Callbacks 8. What is the output? (array.filter) — B. [3, 4] 9. Which is best for spacing between flex items? — B. gap 10. What does querySelector do? — B. First match 11. Layout direction (Tailwind flex-col md:flex-row) — B. Column on small, row on medium+ 12. Why does map return undefined? — B. Missing return 13. What does JSON.stringify() do? — A. Converts object to string 14. What does Array.push() do? — A. Adds element to the end 15. What is the use of the spread operator (...) ? — C. Copying or merging arrays/objects 16. How to save data in LocalStorage? — B. setItem('key', 'value') 17. Difference between const and let — A. const cannot be reassigned 18. == vs === — B. === checks both value and type 19. What is the output of typeof null? — C. "object" 20. What is Hoisting? — A. Moving declarations to the top 21. Why is useState used in React? — B. To manage component state 22. What does p-4 mean in Tailwind? — A. Padding on all sides 23. What does Array.reduce() do? — B. Accumulate values to a single result 24. Why use event.preventDefault()? — A. Stops default browser behavior 25. Which method does fetch() use by default? — A. GET 🚀 #javascript #reactjs #webdevelopment #frontenddeveloper #coding #learninginpublic #Akbiplob

🛢️ Barrel imports look clean, but unfortunately That index.ts might be your slowest file 👇 A barrel import is when you create an index.ts that re-exports everything from a folder, so consumers can import from a single path instead of digging into individual files. It's not free though. 1️⃣ One import loads everything — You imported Button but the bundler parses the entire barrel. Modal, Input, and all their deps tag along. Tree-shaking helps sometimes, not always. 2️⃣ Dev server startup tanks — Webpack and Turbopack resolve the full module graph behind every barrel before serving anything. Nest barrels inside barrels and you're resolving hundreds of modules for one component. Next.js added optimizePackageImports specifically for this. 3️⃣ Circular deps get invisible — A imports from the barrel, barrel imports B, B imports A. The cycle is hard to trace because the barrel hid every direct relationship between modules. 4️⃣ Module boundaries disappear — Everything behind index.ts means teams stop thinking about public vs private. Internal details leak and every component ends up depending on everything else. One barrel at the public API boundary of a package is fine. A tiny utils/index.ts with three pure functions won't hurt either. The pain starts with barrels inside features and barrels importing other barrels. Have you ripped out barrel imports from a project, or are you still using them everywhere? #JavaScript #TypeScript #WebDev #React #Frontend