Stop Relying on NPM: Leverage Native Web APIs

Hydration errors are one of the fastest ways to waste hours in React. Next.js 16.2 just made them much easier to debug. here’s the simple version 👇 When an app loads, part of it is rendered on the server and then “hydrated” in the browser. If those don’t match → things break ⚠️ Earlier, debugging this felt like guesswork. Now, it’s a lot more direct. What improved in 16.2: 🔍 Clearer error messages (you can trace the exact mismatch) 🧹 Fewer false warnings 🧩 More predictable server/client behavior A mistake I made early on 👇 I hit a hydration error while fetching data from a protected (auth-based) API. At that time, I didn’t understand the root cause. Now it’s obvious: The server rendered the UI without auth context, but the client had an authenticated user. Result → mismatch between server HTML and client state ⚠️ Fix: Moved the data fetching to the client using useEffect. Why this actually works: It delays rendering of dynamic, auth-dependent data until the client has the correct state — keeping server and client output consistent. takeaway: Hydration errors are rarely framework bugs. They’re usually mismatched assumptions between server and client. Next.js 16.2 doesn’t fix your logic — it just makes the problem visible faster. Question: What’s the worst hydration bug you’ve had to debug? #NextJS #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering

Just learned something fundamental about how browsers work — Event Bubbling 🫧 I was building a P2P file sharing app and ran into a weird bug. I had a file drop zone that opens a file picker on click. Inside it, I added a "Send" button. Every time I clicked "Send" — the file picker would open again. 😅 Turns out this is Event Bubbling. When you click any element in the browser, the click doesn't just fire on that element. It fires on the element, then its parent, then its parent's parent — all the way up to the document. Like a bubble rising in water. Starts at the bottom, rises up. ❌ Without stopPropagation: <div onClick={() => openFilePicker()}>  ← 2. fires here too 😱  <button onClick={() => sendFile()}>  ← 1. you clicked here   Send  </button> </div> ✅ With stopPropagation: <div onClick={() => openFilePicker()}>     ← never fires ✓  <button onClick={(e) => {   e.stopPropagation()            ← bubble stops here   sendFile()  }}>   Send  </button> </div> One line fix. But understanding WHY it happens makes you a better developer than just copy-pasting the solution. #javascript #webdevelopment #frontend #buildinpublic #reactjs

Most React performance issues don’t come from React. They come from how we use it. If your app feels slow, chances are you’re doing one of these 👇 1️⃣ Unnecessary Re-renders Every state/prop change can trigger re-renders. Fix: • Use React.memo for pure components • Avoid passing new object/function references 2️⃣ Missing Memoization Expensive calculations running on every render. Fix: • Use useMemo for heavy computations • Use useCallback for stable function references 3️⃣ Large Component Trees One change → entire tree re-renders. Fix: • Break into smaller components • Lift state only when needed 4️⃣ Rendering Large Lists Rendering 1000+ items kills performance. Fix: • Use virtualization (react-window, react-virtualized) 5️⃣ Blocking the Main Thread Heavy logic blocks UI updates. Fix: • Move work to web workers • Defer non-critical updates 6️⃣ Poor API Handling Sequential API calls slow everything down. Fix: • Use Promise.all for parallel calls • Cache responses when possible 💡 Most React optimizations are not about adding libraries. They’re about understanding rendering behavior. Small fixes → huge impact. Which React optimization gave you the biggest performance win? 👇 #React #Frontend #WebPerformance #JavaScript #SoftwareEngineering #WebDevelopment

Most explanations make React server components sound harder than they actually are but they're not. Simply... React Server Components are just components that run on the server instead of the browser, so they don't send unnecessary JavaScript to the client and only the final rendered output reaches the UI. Say like moving heavy work away from the user's device and handling it where it's more efficient 😎 Behind the scenes, React executes these components on the server, fetches data directly there like from a DB or API without needing extra client side calls, converts the result into a lightweight payload, and streams it to the browser where it gets merged with interactive parts handled by client components. Why this actually matters is simple, less JavaScript in the browser means faster load, smaller bundles, better performance, and your sensitive logic stays on the server while still keeping the UI interactive where needed. Follow Sakshi Jaiswal ✨ for more quality content ;) #Frontend #React #Sakshi_Jaiswal #FullstackDevelopment #javascript #TechTips #ServerComponents #ServerSideRendering #NextJs

Your frontend .env file is not a safe place for API keys. And most teams don’t realise this until it’s too late. I get why it feels safe. You pull the key out of the code, stick it in .env, add it to .gitignore and move on. Feels responsible. Feels clean. But in Next.js anything you prefix with NEXT_PUBLIC_ gets bundled straight into the client at build time. It ships to the browser. Anyone who opens devtools and digs through your JS bundle can find it sitting right there. The .env file didn’t protect you. It just changed where you typed the key. This is not a bug. It’s how it works. The browser needs to read that value so Next.js puts it in the bundle. But a lot of teams treat the .env file like a vault and never stop to question what actually happens at build time. The real fix is your sensitive keys should never reach the frontend at all. Route those calls through a server side layer. Your BFF, an API route, server actions, whatever fits your setup. The key lives on the server. The browser never sees it. Configuration in .env is fine. Secrets in .env on the frontend is just security theatre. Anyways that’s my two cents. Have you ever worked in a codebase where sensitive keys were just sitting in the bundle? How did that get caught? #NextJS #React #Frontend #WebSecurity #JavaScript #TechLead #WebDevelopment #Sydney

A few weeks ago, while building a web application, I ran into an error when I made an API call. turns out It wasn't my code. It was a CORS error triggered by the browser. Browsers enforce something called the Same-Origin Policy, security mechanism that blocks requests to external servers that don't explicitly allow cross-origin requests. The fix was a proxy server , a small Node.js backend that sits between the browser and the external server. Instead of the browser calling the external server directly, it calls my own backend. My backend makes the request server-to-server, with no browser restrictions in the way. I wrote a full tutorial walking through exactly how this works, why it happens, and how to fix it , using a real working demo. 🔗 Link in the comments. #webdevelopment #javascript #nodejs #cors #frontend #tutorial

Why your Next.js upgrade is throwing searchParams errors ❓. 👇 If you are upgrading an app to Next.js 15 or 16, your dynamic pages are probably throwing errors. For years, we accessed URL queries and route parameters exactly like normal props. But as Next.js pushes toward a fully async rendering model, accessing request-specific data synchronously actually blocks the server from preparing the rest of the page. To fix this, Next.js made dynamic APIs asynchronous. ❌ The Legacy Way (Next.js 14): Reading searchParams directly as an object. This forces the entire component tree to wait for the user's request, preventing the server from pre-rendering the static shell of your page. ✅ The Modern Way (Next.js 15+): You must await the searchParams prop. • Performance: It allows Next.js to start rendering your layout before the dynamic data is even requested. • Future-Proof: This aligns your code with the new React Server Components async architecture. • Clean: It is a simple 1-line syntax update that prevents massive hydration bugs. The Shift: We are moving away from treating the server environment like a synchronous browser window. A technical guide on migrating to Next.js 15 and 16 by resolving searchParams and params errors. Learn why dynamic APIs are now asynchronous and how to await searchParams in your React Server Components to improve performance and prevent rendering bugs. #NextJS #NextJS15 #NextJS16 #ReactJS #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #WebDev #CodingTips #FrontendDevelopers

JavaScript moves fast. But 42% of npm packages have not been updated in 2+ years. Take a moment to think about that. 🤯 We all love npm because it gives us: 📦 Millions of packages ⚡ Faster development 🧩 Easy way to build complex apps But this same strength is slowly becoming a big technical problem. Today, most production apps include: 🔗 Hundreds of hidden dependencies 🧑💻 Important packages maintained by just one person 🪦 Some packages that are no longer maintained ⏳ Security fixes taking longer than before Real problems we are facing 👇 🚨 Supply chain risk If one popular package gets hacked, thousands of apps can break. It has happened before. It can happen again. 🐘 False sense of performance We try to optimize our code… but still ship large bundles because of many dependencies. 🧠 Why frameworks are becoming bigger Frameworks like Next.js and others are adding more built-in features. Not to control developers. But to reduce complexity and risk. 🔮 The future of JavaScript may not be about more packages. It may be about fewer, better, more trusted tools. Because speed without stability can lead to big problems later. 💣 Do you think we are moving toward a dependency crisis in frontend development? #javascript #npm #webdev #softwarearchitecture #frontend

useEffect is the most abused hook in React. Here's what to use instead. I've reviewed hundreds of React codebases. useEffect is in the wrong place in about 60% of them. Not because developers are careless. Because nobody explained when NOT to use it. Here are the cases I see constantly — and what actually belongs there: // ❌ Case 1: Deriving state useEffect(() => { setFullName(`${firstName} ${lastName}`) }, [firstName, lastName]) // ✅ Just compute it const fullName = `${firstName} ${lastName}` No state. No effect. No re-render bug. // ❌ Case 2: Fetching data on mount (with App Router) useEffect(() => { fetch('/api/user').then(...) }, []) // ✅ Use a Server Component or TanStack Query // Data fetching is not a side effect in modern React // ❌ Case 3: Syncing two pieces of state useEffect(() => { if (selectedId) setDetails(getDetails(selectedId)) }, [selectedId]) // ✅ Derive during render const details = selectedId ? getDetails(selectedId) : null The React team has said explicitly: if you're using useEffect to sync state with other state, you probably have one piece of state too many. useEffect is for: → Connecting to external systems (WebSocket, third-party libraries, browser APIs) → Setting up subscriptions → Manual DOM manipulation That's mostly it. If you're using useEffect for anything that feels like when X changes, update Y, there's almost certainly a cleaner way. What's the strangest useEffect usage you've come across? #React #JavaScript #TypeScript #FrontendDevelopment #WebDevelopment

🚀 Understanding CORS (Cross-Origin Resource Sharing) Simplified for Developers If you’ve ever seen this error in your browser 👇 “No 'Access-Control-Allow-Origin' header is present…” Congrats — you’ve met CORS 😅 Let’s break it down in the simplest way 👇 🔹 What is CORS? CORS is a browser security feature that controls how your frontend and backend communicate when they are on different origins. 👉 Example: Frontend: http://localhost:3000 Backend: http://localhost:5000 Different ports = different origin → 🚫 blocked by default 🔹 Why does it exist? To protect users from malicious websites making unauthorized requests using their browser. 🔹 How does it work? When your frontend makes a request: Browser sends the request with origin info Server responds with permission headers Browser decides: allow ✅ or block ❌ 🔹 Common Fix (Node.js / Express) import cors from "cors"; app.use(cors({ origin: "http://localhost:3000" })); 🔹 Key Points to Remember ✔️ CORS is enforced by the browser ✔️ Backend must allow the origin ✔️ Postman/cURL don’t care about CORS ✔️ Never blindly use * in production 🔹 Pro Tip 💡 If you're working with React / Next.js + API, always configure CORS early — it saves hours of debugging. 💬 Have you faced CORS issues before? What was the hardest bug you solved? #WebDevelopment #JavaScript #ReactJS #NextJS #Backend #FullStack #CORS #Programming