Make-it.Run’s Post

Why do React apps feel instant — even when switching pages? In a regular website, clicking a link.... loads a completely new page from the server. React apps don't work that way. React Router lets you switch between pages  without any server request or full page reload. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀: → URL changes in the browser → React Router reads the new URL → Renders the matching component → No page refresh, instant navigation 𝗕𝗮𝘀𝗶𝗰 𝘀𝗲𝘁𝘂𝗽: <Route path="/home" element={<Home />} /> <Route path="/about" element={<About />} /> <Route path="/dashboard" element={<Dashboard />} /> This is why React apps feel fast and smooth  compared to traditional websites. #reactjs #webdevelopment #javascript #MERN

Behind the scenes of my new portfolio 🛠️ Instead of using a template, I decided to build from the ground up to explore more of the Next.js ecosystem. One of the coolest parts was integrating the Resend API. Why Resend? I wanted a clean way to handle contact submissions without relying on messy SMTP setups. Using Resend with Next.js Server Actions made the "Contact Me" flow incredibly smooth and reliable. The full stack: 🔹 Framework: Next.js (App Router) 🔹 Styling: Tailwind CSS 🔹 Contact: Resend API 🔹 Deployment: Vercel You can see the results here: https://lnkd.in/dmcG7rV7 Special thanks to everyone who gave me feedback during the build! #Typescript #NextJS #SoftwareDeveloper #ResendAPI #Frontend

CORS errors once felt like an unsolvable mystery to me. I was building a React 18 app with a Node.js backend. Everything seemed fine locally, but as soon as I deployed, users hit a wall of "CORS policy" errors. My first thought? Something was broken on the backend. → CORS stands for Cross-Origin Resource Sharing. It's a browser security feature that restricts web pages from making requests to a different domain than the one that served the web page. It’s not a backend bug; it’s your browser protecting you. → I learned that the issue often arises when a React app hosted on one server tries to communicate with an API hosted on another. The browser blocks this request unless the server explicitly allows it by sending specific headers. → The "Aha!" moment was realizing that I needed to configure my backend to respond with the right CORS headers. In my case, adding Access-Control-Allow-Origin: * to the server's response headers solved the issue. It was like unlocking a door that had been firmly shut. After understanding CORS, I stopped wildly guessing at solutions and started looking at the problem from the browser's perspective. It made debugging faster and less frustrating. Have you ever faced a CORS issue that took you down a rabbit hole before you found the fix? How did you handle it? #MERNStack #JavaScript #WebDevelopment #CORS #ReactJS

In React, you can show or hide components based on conditions 3 ways to do it....  1. 𝗶𝗳/𝗲𝗹𝘀𝗲 if (isLoggedIn) return <Dashboard /> else return <Login /> 2. 𝗧𝗲𝗿𝗻𝗮𝗿𝘆 𝗼𝗽𝗲𝗿𝗮𝘁𝗼𝗿 {isLoggedIn ? <Dashboard /> : <Login />} 3. && 𝗼𝗽𝗲𝗿𝗮𝘁𝗼𝗿 {isLoggedIn && <Dashboard />} Use && when you only want to show something and have nothing to show otherwise. Use ternary operator when you have two options. This is how every login/logout, loading spinner, and error message works in a React app #reactjs #webdevelopment #javascript #MERN

React Server Components are changing how we build web apps. - They run on the server, so less JavaScript is sent to the browser. This makes apps faster and lighter. - They are now the default in Next.js. - But you need to understand server and client boundaries, and there are some limitations. - Still, it’s a big step towards better performance. What do you think about it? #React #NextJS #WebDevelopment #JavaScript

Stop overcomplicating WebAssembly for compute-heavy web apps — real-world use cases. I've reviewed hundreds of implementations. The best ones? Dead simple. The pattern: - Start with the boring solution - Measure actual bottlenecks - Only then add complexity Premature optimization is real, and it kills projects. What's the simplest solution you've shipped that just worked? #WebDevelopment #TypeScript #Frontend #JavaScript

Stop overcomplicating WebAssembly for compute-heavy web apps — real-world use cases. I've reviewed hundreds of implementations. The best ones? Dead simple. The pattern: - Start with the boring solution - Measure actual bottlenecks - Only then add complexity Premature optimization is real, and it kills projects. What's the simplest solution you've shipped that just worked? #WebDevelopment #TypeScript #Frontend #JavaScript

I thought every React component runs in the browser… Next.js proved me wrong. Day 5 of my 30-day Next.js deep dive. Today I explored Client vs Server Components—and this topic really made me pause and rethink how React apps actually work under the hood. This isn’t just a feature. It changes how you design your entire app. Key Learnings - Components in Next.js are Server Components by default - Server Components run on the server → better performance and smaller bundle size - Client Components are needed for interactivity (state, events, hooks) - "use client" explicitly marks a component for the browser - Mixing both correctly is key to building efficient apps At first, I was confused: “Why isn’t my component working with useState?” Then I realized—it was running on the server. That moment made something click: 👉 Not everything needs to be interactive 👉 And not everything should run in the browser This changed how I think about performance and architecture. I’m starting to think beyond just “making things work” and focusing more on how and where code runs. Because in real-world remote teams, performance and architecture decisions actually matter. For developers working with Next.js—how do you decide when to use a Client Component vs a Server Component? #NextJS #ReactJS #WebDevelopment #FullStackDeveloper #JavaScript #Performance #LearningInPublic #RemoteDeveloper

Most React apps render everything immediately, even components users haven’t scrolled to yet. That means unnecessary work for the browser and slower pages. Here is a custom React hook using Intersection Observer that renders components only when they enter the viewport. Perfect for: • lazy-rendering sections • dashboards with heavy widgets • charts and media components • improving scroll performance • reducing initial load cost Small hook. Noticeable performance win. Try it in your next project and you’ll feel the difference. #reactjs #javascript #webperformance #frontenddevelopment #reacthooks #softwaredevelopment #webdev #codingtips #devcommunity #intersectionobserver #performanceoptimization

🚀 How I actually improved performance in Next.js (beyond the basics) After working on real production apps, I realized performance isn’t about adding more tools - it’s about removing unnecessary work from the client. Here are the changes that made a real difference: 1. App Router + React Server Components Shifted most logic to the server → significantly reduced client-side JS bundle. Less hydration = faster initial load. 2. Selective Dynamic Import Used next/dynamic with { ssr: false } for heavy components (charts, editors, maps). Load only when needed → avoid blocking the main thread. 3. Proper Image Optimization next/image handled WebP, lazy loading, and responsive sizing automatically. Improved Core Web Vitals without extra libraries. 4. Parallel & Deferred Data Fetching Replaced sequential fetching with Promise.all and Suspense. Critical data loads first, non-critical parts are deferred. 5. Caching Strategy (this is where most people get it wrong) Understanding force-cache, no-store, and revalidate is key. Wrong caching can hurt more than no caching at all. 👉 Biggest lesson: Performance isn’t about doing more - it’s about sending less and doing less on the client. Curious what strategies you’re using to optimize Next.js apps 👇 #Nextjs #WebPerformance #Frontend #ReactJS #Programming