DEV Community: Safdar Ali

How AI Changed the Way I Write React Code — 2 Years In

Safdar Ali — Sun, 11 Oct 2026 20:40:04 +0000

I'm Safdar Ali, a frontend engineer in Bengaluru. In late 2024 I installed GitHub Copilot as an experiment. Today — October 2026 — Cursor Agent with Claude is open on every project, including this portfolio at safdarali.in. Two years of daily ai react development did not make me obsolete. It changed where I spend cognitive effort: less on boilerplate, more on architecture, review, and the questions AI cannot answer. This is an honest accounting — not a pitch for any tool.

What actually changed in my daily work

Speed on scaffolding. New components, API route stubs, Zod schemas, and test files appear in minutes instead of half-hours. I start further along on every task.

Context switching dropped. I used to alt-tab between docs, Stack Overflow, and my editor constantly. Now I ask the agent to explain an unfamiliar API against my actual codebase — the answer is contextual, not generic.

Refactors got cheaper. Renaming a prop across 12 files, converting client fetches to Server Components, adding TypeScript strict types to a legacy module — these used to be "schedule for Friday" tasks. Now they're afternoon tasks with review.

My commit size changed. More frequent, smaller commits. AI generates chunks; I review and merge chunk by chunk instead of writing 400-line PRs manually.

// 2024 — I wrote every line of this by hand

export function useDebounce<T>(value: T, delay: number): T {

  const [debounced, setDebounced] = useState(value);

  useEffect(() => {

    const timer = setTimeout(() => setDebounced(value), delay);

    return () => clearTimeout(timer);

  }, [value, delay]);

  return debounced;

}

// 2026 — AI generates this in 3 seconds; I verify edge cases and add tests

// My value-add: knowing WHEN to debounce, not typing the hook from memory

What did not change — and probably never will

Architecture decisions. Server Component vs client component boundaries, state management choices, caching strategy — AI suggests patterns but cannot know your product constraints, team size, or traffic profile.

Debugging production incidents. AI helps read stack traces. It does not replace opening DevTools at 11pm when a hydration mismatch only appears on Android Chrome in India.

Code review judgment. Someone must reject the confident wrong output. That someone needs to understand React reconciliation, not just prompt engineering.

Stakeholder communication. Translating "we need ISR here because catalog updates hourly" into business language — no model does that for you.

What surprised me most over two years: AI did not reduce total hours worked — it shifted where those hours go. I spend less time writing boilerplate and more time in code review, architecture discussions, and debugging the subtle bugs AI introduces — wrong dependency arrays, missing error boundaries, imports from packages not in package.json. The job got more senior, not more absent.

Pair programming changed too. When I mentor juniors in Bengaluru, we use AI together — they prompt, I ask why they accepted the output, we fix it together. That teaches review skills faster than solo tutorial watching. The tool is the same; the mentorship model adapted.

Skills that matter more now — ranked honestly

Skill	Importance in 2024	Importance in 2026	Why
Reading diffs critically	High	Critical	AI generates more code to review
React fundamentals	Critical	Critical	Cannot debug AI output without them
Typing speed / memorisation	Moderate	Lower	Autocomplete handles syntax
System design	High	Higher	AI fills files; you design boundaries
Prompt/task specification	Low	High	Bad prompts waste more time now
Testing discipline	High	Critical	Safety net for AI-generated code
Security awareness	High	Critical	AI leaks patterns, misses auth gaps

Before and after — same feature, two eras

Adding a contact form to a Next.js portfolio — the task I did for this site in 2024 vs 2026.

// BEFORE (2024) — ~4 hours total

// 1. Create API route manually (30 min)

// 2. Write client form with useState validation (45 min)

// 3. Style with Tailwind trial-and-error (60 min)

// 4. Add loading/error states (30 min)

// 5. Debug CORS and env vars (45 min)

// 6. Write tests (30 min)

// AFTER (2026) — ~90 minutes total

// 1. Agent scaffolds Server Action + Zod validation (5 min gen, 15 min review)

// 2. v0 generates form UI, I wire action prop (10 min gen, 20 min review)

// 3. Manual: rate limiting, honeypot, email provider integration (40 min)

// 4. Tests generated, I add edge cases (10 min)

// Time saved: ~2.5 hours. Time still required: integration + review.

The saved time went into performance work and content — not into leaving early. AI shifted the work mix, not the total output expectation.

Code quality did not automatically improve — it shifted form. I write fewer lines manually but read more lines in review. Net lines of code per feature dropped roughly 20% on client projects where AI handled boilerplate, but bug density stayed similar when measured per thousand lines. The bugs moved from typos to logic errors in AI-generated conditionals — a different debugging skill, not fewer bugs by default.

What this means if you are learning React in India

Juniors ask me: "Should I learn to code if AI writes it?" Yes — but learn differently. Skip memorising array method signatures; do not skip building a todo app without AI so you understand state updates. Use AI to explain errors, not to skip the error entirely.

Interviewers in Bengaluru still ask you to walk through a component you wrote. If AI wrote all of it and you cannot explain useEffect dependencies, you will not pass. The bar moved from "can you type code" to "can you own code."

// Bad learning loop — paste AI output, ship, repeat

// You never build mental models

// Good learning loop — AI as tutor

// 1. Try writing the hook yourself (15 min)

// 2. Ask AI to review YOUR code, not generate fresh

// 3. Compare its suggestions to your attempt

// 4. Write the final version by hand with its hints

export function ProductFilter({ onFilter }: { onFilter: (q: string) => void }) {

  const [query, setQuery] = useState("");

  const debounced = useDebounce(query, 300);

useEffect(() => {

    onFilter(debounced);

  }, [debounced, onFilter]);

return <input value={query} onChange={(e) => setQuery(e.target.value)} />;

}

Mistakes I made adopting AI too fast

Shipping AI-generated auth logic without reading it — found a missing CSRF check in review, not in production, luckily. Accepting overly abstracted code because it looked "clean" — three files for what should have been one function. Stopping practice on fundamentals because autocomplete felt good enough — until a whiteboard interview reminded me why muscle memory matters.

The fix was rules, not quitting AI: never merge agent output without reading every changed line; never let AI touch auth, payments, or PII handling without manual security review; keep one personal project per month with AI disabled to stay sharp.

Tools will keep improving — faster models, better repo indexing, cheaper inference. The developers who treat that as leverage rather than replacement will compound their careers. The ones who stop learning fundamentals because autocomplete feels good enough will hit a ceiling in interviews and production incidents. I have seen both outcomes in my network across India's tech hubs over the last two years.

My YouTube audience often asks whether AI makes React tutorials obsolete. No — it makes understanding React more valuable. When anyone can generate a component, the developer who explains why it re-renders, why keys matter, and why the Server Component boundary exists becomes the one teams hire. That is the real shift behind ai react development 2026.

My weekly rhythm with AI in 2026

Monday: plan features manually — no AI for architecture decisions. Tuesday–Thursday: Cursor Agent for implementation, Copilot tab completion while I edit agent output. Friday: code review day — re-read the week's merges without AI assist, run Lighthouse and tests, fix anything that slipped through. Weekend: one hour on personal learning with AI disabled — currently revisiting TypeScript generics the slow way.

That rhythm keeps AI as accelerator, not autopilot. The Friday review catches the subtle bugs — missing dependency arrays, hardcoded API URLs, accessibility gaps — that autocomplete does not flag because they are syntactically valid. Two years in, this rhythm matters more than which model or editor I use.

Where ai react development goes from here

Agents will get better at multi-step tasks — migrations, test coverage, dependency upgrades. They will not replace the engineer who decides whether a migration is worth the risk this sprint. The developers who thrive will treat AI like a fast junior: delegate boilerplate, review everything, own the architecture.

I ship roughly 3x more features per month than in 2024, measured by merged PRs on client work — not because AI writes 3x the code, but because the idle time between "I know what to build" and "first working draft" collapsed. That is the real ai react development 2026 story.

Document your own before/after metrics if you adopt AI tools seriously — merged PRs per week, time from ticket to staging, lines changed in review versus lines changed manually. Without numbers, you will not know if AI actually helps your workflow or just feels faster because typing is more entertaining. I review my metrics monthly and adjust tool usage accordingly.

The single takeaway

AI changed my React workflow profoundly — not by replacing thinking, but by removing friction between thinking and implementation. Fundamentals matter more, not less, because the bottleneck moved from typing to judgment. Learn React deeply, use AI aggressively, review ruthlessly.

Two years from now the tools will look different — new models, new editors, maybe AI built into browsers. The pattern will hold: engineers who understand their stack and review AI output will ship faster than engineers who either reject AI entirely or accept it blindly. Meet in the middle. That is where the career growth lives in ai react development 2026 and beyond.

If you are early in your career, prioritise understanding over speed for the next six months — use AI to explain code you wrote, not to write code you cannot explain. The productivity multiplier kicks in once fundamentals are solid; before that, AI mostly hides gaps that interviews expose.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Jev Is Not an LLM. That Is the Point.

Safdar Ali — Thu, 24 Sep 2026 08:06:46 +0000

Most "AI features" are not writing tasks. They are decisions.

Is this ticket urgent? Which queue owns it? Is this shell command safe to run? Should this request go to a small model, a large one, or a person?

A language model can answer all of those. It does it by generating text, one token at a time, even when you asked for JSON. Jev, from TypeSafe AI, does not generate text at all. You hand it a piece of state and a set of questions whose answers you already defined. It fills those answers in one pass and attaches a confidence score to each one.

That tradeoff is the product. Jev cannot write the email, the summary, or the code. Your program still decides what to do with the judgment.

What you are actually calling

TypeSafe calls Jev a System One model, after the fast, intuitive half of Daniel Kahneman's Thinking, Fast and Slow. The name Jev comes from William Stanley Jevons: when a resource gets cheap enough, people find far more uses for it. The bet is that a decision cheap enough to put inside ordinary control flow gets used in places a frontier chat model never will.

The interface is closer to a function than to a chat:

	A language model	Jev
Output	A string you parse	A value you declared up front
Sampling	One token after another	Every answer in the same request
Uncertainty	Only if you ask, and often overconfident	A confidence score on every answer
Failure mode	Wrong words, broken JSON, a type you did not expect	A wrong choice inside the types you allowed

TypeSafe's published pricing is $0.042 per million input tokens, with output tokens not billed. They report end-to-end times of about 70–500ms, and on their own workflow evals they cite figures around 190× faster and 440× cheaper than the large models they compared against. Those numbers are their benchmark, on workflows their own team wrote, scored against other labs' models. Treat them as a reason to measure your path, not as a number to put in a launch post.

Schema match is a harder claim, and a narrower one. Jev cannot return a string when the field is an enum. It can still pick sales when billing was right. You fixed the shape. You did not get correctness for free.

Put the question on the type, not in the prompt

If you have used Pydantic AI, the call looks like any other structured-output agent. Install the TypeSafe extra and set TYPESAFE_API_KEY.

pip install "pydantic-ai-slim[typesafe]"
export TYPESAFE_API_KEY="your-api-key"

The habit that does not carry over from a language model: the prompt is only the material being judged. The questions live on the output type. A question written into the prompt is more text to judge, not an instruction.

from typing import Literal

from pydantic import BaseModel, Field
from pydantic_ai import Agent

class Ticket(BaseModel):
    """Triage a support ticket."""

    urgent: bool = Field(description="Does this need a reply within the hour?")
    area: Literal["billing", "bug", "account", "other"] = Field(
        description="Which team owns it?"
    )

agent = Agent("typesafe:jev-latest", output_type=Ticket)
result = agent.run_sync(
    "You charged me twice and my account is overdrawn. I need this reversed today."
)
print(result.output)
# urgent=True area='billing'

Several fields go out together. That is where the latency win comes from: independent judgments are not separate generation rounds. Extra fields cost input tokens, not another round trip.

Ask one thing per field. "Is this a good ticket?" is several judgments wearing one name. Jev will still return something, often with low confidence, and you will notice too late. Split it. Combine the answers in code, where the rule is exact.

A str field, an unbounded number, or a datetime is rejected before the request is sent. If the answer is prose, this is the wrong model.

Confidence is the part you branch on

A boolean becomes True when Jev's probability of yes is at least typesafe_boolean_threshold, which defaults to 0.5. That default is a coin flip. It is the wrong bar when the two mistakes do not cost the same. Raising the threshold means a True has to be earned, which is what you want for "safe to run this command with no one watching."

The margin on each field is on the response, not on the model instance:

details = result.response.provider_details or {}
confidence = details.get("confidence", {})
# {'urgent': 0.91, 'area': 0.74}  — illustrative

confidence here is a margin, not "the probability this label is correct." For a yes/no it measures how far the probability sits from the threshold that decided it. For a pick-one, the full distribution is in provider_details['probabilities'].

A practical split:

High margin: let code act.
Middle: send the same state to a stronger generative model.
Low: ask a person.

jev-latest moves when TypeSafe ships a release, and the numbers under a tuned threshold can move with it. Once a bar is calibrated on your own labels, pin a version such as typesafe:jev-1.13.0.

If the honest answer is sometimes "not enough information," put that in the type. A yes/no with no third option forces a side.

Where it fits, and where it does not

Use Jev for the small semantic branch that used to be either a brittle regex or a full model call:

Routing a ticket, a tool call, or a model.
Scoring a rubric you defined (ordered levels, each one described).
Checking an agent step: did it finish, did it leave the requested scope, does a human need to see this?
Guardrails around something a language model already wrote.

Keep a language model for generation and for reasoning that does not fit in one judgment. Keep ordinary code for rules you can write down: amount greater than a limit, a missing field, an allow-list. Jev sitting in the middle does not replace either of those.

Two design limits are worth knowing before you sketch an architecture. Choice lists top out at 255 options, and a high-cardinality pick may be scored in two stages. Fields in the same request are independent, so one answer cannot depend on another answer from that same call. If the second judgment needs the first, make them two steps.

A small architecture, not a new model in every slot

exact rule            → code
bounded judgment      → Jev
writing or reasoning  → a language model
high-stakes uncertainty → a person

The useful question is not which model to standardize on. It is what kind of intelligence a given step needs. If the step is a decision with answers you can name in advance, generating those answers token by token is a lot of machinery for a branch.

Jev is in early access. The TypeSafe announcement has their evals and the caveats attached to them. The Pydantic AI TypeSafe docs are the practical reference for field types, thresholds, and provider_details.

☕ If This Helped You

I publish free tutorials and write-ups like this regularly.

If this article saved you time:

👉 Buy me a coffee:

https://buymeacoffee.com/safdarali

👉 Subscribe to my YouTube channel (free):

https://www.youtube.com/@safdarali_?sub_confirmation=1

More about how I work: safdarali.in/about
Projects and case studies: safdarali.in/projects

Next.js App Router Complete Beginner Guide 2026

Safdar Ali — Fri, 10 Jul 2026 18:30:00 +0000

The nextjs app router tutorial gap is real: official docs are reference-heavy, and beginners still think in Pages Router (pages/index.tsx). App Router uses folders in app/ where the file name tells Next.js what to do. I migrated client sites in 2024–2025 and teach this sequence on my YouTube channel. Follow these steps in order — layout, page, loading, then server fetch.

Mental model — folders are routes

Every folder under app/ maps to a URL segment. Special files: page.tsx = UI, layout.tsx = shared shell, loading.tsx = skeleton while slow segments load.

app/

  layout.tsx      → wraps ALL routes

  page.tsx        → URL: /

  about/

    page.tsx      → URL: /about

  blog/

    page.tsx      → URL: /blog

    [slug]/

      page.tsx    → URL: /blog/my-post

No React Router install. Rename a folder, you rename a route. That is the core App Router win.

If you are coming from Create React App, delete the mental model of a single App.tsx with a Switch. You will have multiple layout.tsx files at different depths — root for html/body, nested for dashboard sidebars. Each layout wraps only its subtree.

Step 1 — Root layout (HTML shell once)

// app/layout.tsx

import type { Metadata } from "next";

import "./globals.css";

export const metadata: Metadata = {

  title: "My App",

  description: "Beginner App Router site",

};

export default function RootLayout({

  children,

}: {

  children: React.ReactNode;

}) {

  return (

    <html lang="en">

      <body className="min-h-screen bg-white text-neutral-900">

        <header className="border-b p-4">My Site</header>

        <main>{children}</main>

      </body>

    </html>

  );

}

Layouts do not remount when navigating between child pages — perfect for nav bars and fonts. Keep providers that must persist here (theme, analytics).

Step 2 — First page

// app/page.tsx — home route

export default function HomePage() {

  return (

    <section className="p-8">

      <h1 className="text-3xl font-bold">Welcome</h1>

      <p>Your first App Router page — no use client needed.</p>

    </section>

  );

}

Default export must be a component. This is a Server Component unless you add "use client" at the top.

Step 3 — loading.tsx for perceived speed

// app/blog/loading.tsx — shows while blog segment loads

export default function BlogLoading() {

  return (

    <div className="animate-pulse space-y-4 p-8">

      <div className="h-8 w-48 rounded bg-neutral-200" />

      <div className="h-4 w-full rounded bg-neutral-200" />

      <div className="h-4 w-3/4 rounded bg-neutral-200" />

    </div>

  );

}

Next.js wraps the segment in Suspense automatically. Users see skeletons instead of frozen UI — critical on Indian mobile networks.

Step 4 — Server Component fetch (no useEffect)

// app/blog/page.tsx

type Post = { slug: string; title: string };

async function getPosts(): Promise<Post[]> {

  const res = await fetch("https://api.example.com/posts", {

    next: { revalidate: 3600 },

  });

  if (!res.ok) throw new Error("Failed to load posts");

  return res.json();

}

export default async function BlogPage() {

  const posts = await getPosts();

  return (

    <ul className="space-y-2 p-8">

      {posts.map((post) => (

        <li key={post.slug}>

          <a href={"/blog/" + post.slug}>{post.title}</a>

        </li>

      ))}

    </ul>

  );

}

// BEFORE — Pages Router habit (client fetch)

"use client";

useEffect(() => fetch("/api/posts").then(/* ... */), []);

// AFTER — async server component

// Data ready before HTML ships — better SEO and LCP

Deeper caching rules: SSR vs SSG vs ISR. Performance tuning: 60% load time case study.

App Router files — quick comparison table

File	Purpose	Required?
layout.tsx	Shared UI wrapper	Root required
page.tsx	Route UI	Yes per route
loading.tsx	Loading skeleton	Optional
error.tsx	Error boundary	Optional
not-found.tsx	404 UI	Optional
route.ts	API endpoint	Optional

Step 5 — Add client components only as leaves

// components/CounterButton.tsx

"use client";

import { useState } from "react";

export function CounterButton() {

  const [n, setN] = useState(0);

  return <button onClick={() => setN(n + 1)}>Clicked {n} times</button>;

}

// app/page.tsx — server page imports client leaf

import { CounterButton } from "@/components/CounterButton";

export default function HomePage() {

  return (

    <section>

      <h1>Home</h1>

      <CounterButton />

    </section>

  );

}

Read RSC vs client components before marking whole pages as client — that is the beginner mistake that balloons bundle size.

Step 6 — Dynamic routes and params

// app/blog/[slug]/page.tsx

type Props = { params: Promise<{ slug: string }> };

export default async function PostPage({ params }: Props) {

  const { slug } = await params;

  const post = await getPost(slug);

  if (!post) return <p>Not found</p>;

  return <article><h1>{post.title}</h1></article>;

}

In Next.js 15, params is a Promise — await it. TypeScript strict mode helps catch forgotten awaits — strict mode guide.

Learning path after this guide

Week 1: layouts + pages + loading. Week 2: server fetch + one dynamic route. Week 3: one client form with Server Action. Week 4: deploy to Vercel and run Lighthouse. If you are choosing between stacks first, read Next.js vs React. Organise folders early with project structure guide.

For AI-assisted coding, see Cursor + Claude workflow — but build this hello-world tree by hand once so file conventions stick.

My production setup

In production I scaffold with root layout, route groups for marketing vs app, loading.tsx on slow segments, and async server pages for public content. This portfolio follows the same pattern — thin app/blog/.../page.tsx files, heavy logic elsewhere.

At my day job, beginners who complete these six steps ship their first internal page in a week — faster than learning Pages Router and relearning later.

The single takeaway

App Router = folders + special files. Layout once, page per route, loading for UX, async server fetch for data. Client components are seasoning, not the main dish.

Related: React 19 features. Contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

WCAG 2.2 Accessibility for React Developers — Practical Guide

Safdar Ali — Thu, 09 Jul 2026 18:30:00 +0000

I'm Safdar Ali, a frontend engineer in Bengaluru. Last quarter I audited a client dashboard that looked polished — clean Tailwind, smooth transitions, Lighthouse performance in the 90s — and failed basic keyboard navigation in under two minutes. Tab order jumped randomly, modals trapped nothing, and icon-only buttons had no labels. WCAG 2.2 is not a legal checkbox for enterprise contracts alone. It is how you ship React UI that works for everyone: screen reader users, keyboard-only users, people on slow 4G with zoom enabled, and your future self debugging at 11pm. This guide covers the wcag 2.2 react patterns I run before every merge.

Why WCAG 2.2 matters for React in 2026
WCAG 2.2 added criteria that directly affect React apps: focus not obscured, dragging movements, target size minimums, and consistent help. React's component model makes accessibility both easier and easier to break — you can encapsulate good patterns in a shared Dialog component, but you can also copy-paste a div-with-onClick button across forty files.

The legal landscape in India is catching up. Government portals and fintech products increasingly require accessibility audits before launch. Even when nobody asks, inclusive UI reduces support tickets — unclear error messages and broken focus management generate more "the form is broken" emails than actual backend failures.

React does not ship accessible components by default. A is focusable; a is not, unless you wire it. Your job is to make the accessible path the default path in your design system.

Focus traps — modals that actually work
A focus trap keeps keyboard focus inside a modal until the user dismisses it. Without one, Tab sends focus to elements behind the overlay — confusing for sighted keyboard users and disorienting for screen reader users who hear content from two layers at once.

How I Structure Large Next.js Projects — Folder Architecture Guide

Safdar Ali — Wed, 08 Jul 2026 18:30:00 +0000

Bad nextjs folder structure does not show up on day one. It shows up at month six when three developers search for the checkout form hook and find four copies. I reorganised a client dashboard after exactly that — this guide is the tree I use now on large App Router projects, why each folder exists, mistakes from my first Next.js apps, and the 10-second findability rule.

Real folder tree — production-shaped layout

my-app/

├── app/                    # routes only — thin pages

│   ├── (marketing)/        # route group — shared layout, no URL segment

│   │   ├── layout.tsx

│   │   ├── page.tsx

│   │   └── pricing/page.tsx

│   ├── (dashboard)/

│   │   ├── layout.tsx

│   │   └── orders/page.tsx

│   ├── api/                # route handlers

│   │   └── webhooks/stripe/route.ts

│   ├── layout.tsx          # root layout

│   └── globals.css

├── components/             # shared UI — buttons, cards, shell

│   ├── ui/

│   └── layout/

├── features/               # business domains — colocated logic

│   ├── auth/

│   │   ├── components/

│   │   ├── hooks/

│   │   └── actions.ts

│   └── orders/

│       ├── components/

│       ├── api.ts

│       └── types.ts

├── lib/                    # server + shared utilities

│   ├── db.ts

│   └── env.ts

├── hooks/                  # truly global client hooks

├── types/                  # global TS types

├── data/                   # static data, blog posts list

└── public/

Routes live in app/. Business logic lives in features/. Generic design system pieces live in components/ui. That separation is the whole game.

Why each folder exists

Folder	Purpose	Do not put here
app/	URLs, layouts, loading.tsx	Fat business logic
features/	Domain modules (orders, auth)	Generic Button
components/ui	Reusable primitives	Order-specific tables
lib/	DB clients, env validation	React components
app/api	Webhooks, REST edge cases	Every form POST (prefer actions)

Thin pages — route files under 40 lines

// app/(dashboard)/orders/page.tsx — orchestration only

import { OrderTable } from "@/features/orders/components/OrderTable";

import { getOrders } from "@/features/orders/api";

export default async function OrdersPage() {

  const orders = await getOrders();

  return (

    <section>

      <h1>Orders</h1>

      <OrderTable rows={orders} />

    </section>

  );

}

If your page file exceeds a screen, extract to features. Pages should read like a table of contents.

Thin pages also make Server Component boundaries obvious: data fetching stays in api.ts or the page, UI in feature components, client interactivity in a single leaf with "use client". When a page mixes all three, reviews slow down and hydration bugs hide in the middle of a 200-line file.

The 10-second findability rule

The rule applies to you six months later, not only new hires. I have opened my own repos and lost minutes searching for a webhook handler buried under utils — that shame is why I enforce feature folders now.

Ask: "Where is the code that sends the password reset email?" If you cannot answer in ten seconds, the structure failed. Correct answer in my tree: features/auth/actions.ts or features/auth/emails.ts — not scattered across utils, hooks, and app/api.

// Naming convention that helps findability

features/orders/

  components/   → OrderTable.tsx, OrderFilters.tsx

  hooks/        → useOrderFilters.ts (client)

  api.ts        → getOrders, createOrder (server-safe)

  types.ts      → Order, OrderStatus

First project mistakes I made

components/ dump with 80 files and no subfolders. utils.ts at 1,200 lines. Duplicating fetch logic in every page instead of feature api modules. Putting Server Actions inside random page files instead of colocated actions.ts.

Another mistake: mirroring REST URLs in folder names under components — components/api/users/get.tsx — which fights App Router conventions. Routes belong in app/; business logic belongs in features/. Mixing them creates two sources of truth for the same URL.

// BEFORE — everything in components/

components/

  OrderTable.tsx

  UserAvatar.tsx

  pricing-card.tsx

  helper.ts

// AFTER — domain colocation

features/orders/components/OrderTable.tsx

features/users/components/UserAvatar.tsx

app/(marketing)/pricing/page.tsx  // thin

Route groups for different shells

// app/(marketing)/layout.tsx — public nav, footer

// app/(dashboard)/layout.tsx — sidebar, auth gate

// URL stays /pricing and /orders — parentheses omit segment

Pair with rendering choices from SSR vs SSG vs ISR guide — marketing group ISR, dashboard group client-heavy.

Path aliases and import direction

// tsconfig paths — "@/": ["./"]

// Allowed import flow:

// app → features → components/ui → lib

// features → lib

// Never: lib → features (inverts layers)

Enforce with ESLint import rules when the team grows past three people.

I also keep a single README.md at the repo root with a one-paragraph map: where routes live, where features live, how to run migrations. The tree in this article is the visual version of that map — new contractors read it before their first PR.

My production setup

In production on this portfolio and client sites: route groups for marketing vs app shells, features/ for blog and contact logic, components/ui for sparkles and buttons. TypeScript strict — see strict mode guide. New engineers onboard by reading features/ first, not app/ line by line.

At my day job, we added a CODEOWNERS file per feature folder — reviews stay scoped. Structure is team policy, not personal taste.

When a feature folder grows past ~15 files, split subdomains — features/orders/checkout/ vs features/orders/history/ — before you invent a second top-level folder that duplicates the domain name.

The single takeaway

Routes in app/, domains in features/, primitives in components/ui. If findability fails the 10-second test, refactor before adding the next feature.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

React useCallback vs useMemo — When You Actually Need Them

Safdar Ali — Wed, 08 Jul 2026 18:30:00 +0000

Junior PRs in my reviews often wrap every function in useCallback and every array in useMemo because a blog post said so. The React Profiler showed the opposite: more memoisation, more comparison work, slower interactions. This usecallback vs usememo guide is profiler-first — what each hook does, when it helps, and the over-memoising mistake I made on a real table.

What each hook actually does

useMemo caches a computed value between renders when dependencies are unchanged. useCallback caches a function reference — it is useMemo for functions.

import { useMemo, useCallback } from "react";

function Dashboard({ rows }: { rows: Row[] }) {

  const total = useMemo(() => rows.reduce((sum, r) => sum + r.amount, 0), [rows]);

const handleExport = useCallback(() => {

    downloadCsv(rows);

  }, [rows]);

return <Toolbar total={total} onExport={handleExport} />;

}

Neither hook prevents re-renders by itself. They only help when a child skips render because props are referentially equal — usually with React.memo.

A common confusion: developers think useMemo stops the parent re-rendering. It does not. The parent still runs its function body every time state changes — useMemo only skips recomputing one expression inside that run. useCallback is the same for function identity. If your performance problem is "the whole page re-renders on every keystroke," move state down or split context before touching memo hooks.

The over-memoising mistake I made

On a 500-row admin table I wrapped every cell formatter in useMemo and passed useCallback handlers to each row. Scroll jank got worse — dependency checks on every scroll event dominated.

// BEFORE — memo soup, slower scroll

const formatted = useMemo(

  () => rows.map((r) => formatCurrency(r.amount)),

  [rows]

);

const onRowClick = useCallback((id: string) => navigate("/row/" + id), []);

// AFTER — virtualise the list, drop per-row memo

import { useVirtualizer } from "@tanstack/react-virtual";

// Only memo expensive derived data used by memoised children

Fix was virtualisation + smaller components, not more hooks. Lesson: measure before memoising.

// BEFORE — unstable inline object recreates every parent render

<HeavyChart config={{ theme: "dark", showGrid: true }} />

// AFTER — stable reference only if HeavyChart is memoised

const config = useMemo(() => ({ theme: "dark", showGrid: true }), []);

<HeavyChart config={config} />

Without React.memo on HeavyChart, the AFTER snippet still re-renders the chart — you paid for useMemo and got nothing. That is the over-memoising pattern: hooks without a memoised consumer.

How I use the React Profiler

Chrome React DevTools → Profiler → record interaction → look for components with long render times and high render counts. Yellow bars mean wasted renders. I fix structure first (split context, move state down, virtual lists), then add memo where a memoised child still re-renders with stable props.

// Wrap only when Profiler shows child re-renders are expensive

import { memo } from "react";

const HeavyChart = memo(function HeavyChart({ data }: { data: Point[] }) {

  // expensive canvas draw

  return <canvas />;

});

// Parent must pass stable data reference

const data = useMemo(() => computePoints(raw), [raw]);

return <HeavyChart data={data} />;

On marketing sites built with Server Components, much of the tree never hydrates — memo hooks on the server branch are pointless. See RSC vs client components.

When to use which — table

Situation	useMemo	useCallback
Expensive calculation	Yes	No
Stable prop to memo child	For objects/arrays	For functions
useEffect dependency	Rarely needed	Sometimes
Primitive props to memo child	No	No
List without virtualisation	Fix list first	Fix list first
Context provider value	Often yes (object)	Callbacks inside value

useCallback — legitimate use with memoised child

"use client";

import { memo, useCallback, useState } from "react";

const SearchInput = memo(function SearchInput({

  onSearch,

}: {

  onSearch: (q: string) => void;

}) {

  console.log("SearchInput render");

  return <input onChange={(e) => onSearch(e.target.value)} />;

});

export function FilterBar() {

  const [query, setQuery] = useState("");

  const onSearch = useCallback((q: string) => setQuery(q), []);

  return <SearchInput onSearch={onSearch} />;

}

Without useCallback, SearchInput re-renders whenever FilterBar state unrelated to search changes — only worth fixing if Profiler proves SearchInput is costly.

useMemo — filtering large lists

const filtered = useMemo(

  () => products.filter((p) => p.name.toLowerCase().includes(query.toLowerCase())),

  [products, query]

);

If the filter runs in under a millisecond on your data size, skip useMemo — the hook overhead can cost more than the loop.

Rule of thumb I teach in reviews

Default: no memo hooks. Add when Profiler shows a problem. useMemo for expensive derived data consumed by memoised children. useCallback for stable handlers passed to those children. Never memoise to silence ESLint exhaustive-deps without understanding why deps change.

React 19 and the future compiler may auto-memoise — until then, stay boring. Performance wins on public sites still come from server rendering and smaller bundles — Next.js performance guide.

My production setup

In production I memoise chart components and heavy derived selectors in dashboards. Marketing pages: almost zero useCallback/useMemo. At my day job I comment why when memo is added — "Profiler: Chart 40ms → 8ms" — so the next dev does not delete it blindly.

When mentoring in Bengaluru, I ask juniors to screenshot Profiler flamegraphs in PRs that add memo hooks — not because I love process, but because it proves they measured. Copy-pasting useCallback from Stack Overflow without a memo child is the most common wasted line I delete in review.

The single takeaway

useCallback stabilises functions; useMemo stabilises values. Both only matter when referential equality blocks wasted work. Profile first, memo second.

Related: React 19 features. Contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Zustand vs Redux Toolkit — Which State Manager in 2026?

Safdar Ali — Tue, 07 Jul 2026 18:30:00 +0000

Global state still matters in 2026 — but most pages should not need it. When they do, the debate is zustand vs redux 2026: Redux Toolkit (RTK) is the enterprise default; Zustand is the minimal store juniors actually read. I have shipped both on dashboards in production. This article implements the same counter plus async user fetch in each, compares bundle size, and ends with what I pick for new repos.

Zustand — counter and async fetch

// store/useAppStore.ts

import { create } from "zustand";

type User = { id: string; name: string } | null;

type State = {

  count: number;

  user: User;

  loading: boolean;

  increment: () => void;

  fetchUser: () => Promise<void>;

};

export const useAppStore = create<State>((set) => ({

  count: 0,

  user: null,

  loading: false,

  increment: () => set((s) => ({ count: s.count + 1 })),

  fetchUser: async () => {

    set({ loading: true });

    const res = await fetch("/api/me");

    const user = await res.json();

    set({ user, loading: false });

  },

}));

// components/CounterPanel.tsx

"use client";

import { useAppStore } from "@/store/useAppStore";

export function CounterPanel() {

  const count = useAppStore((s) => s.count);

  const increment = useAppStore((s) => s.increment);

  return <button onClick={increment}>Count: {count}</button>;

}

No providers, no slices folder — one file, selective subscriptions via selectors. That is why Zustand spreads on small teams.

The async fetch above is intentionally boring — no thunk middleware, just async/await inside the store action. For error handling you extend with try/catch and an error field; for retries you either wrap fetch or move the request to TanStack Query. Zustand does not prescribe async patterns, which is freedom or chaos depending on team discipline.

Redux Toolkit — same features, more structure

// store/appSlice.ts

import { createSlice, createAsyncThunk } from "@reduxjs/toolkit";

export const fetchUser = createAsyncThunk("app/fetchUser", async () => {

  const res = await fetch("/api/me");

  return res.json();

});

const appSlice = createSlice({

  name: "app",

  initialState: { count: 0, user: null as null | { id: string; name: string }, loading: false },

  reducers: {

    increment: (state) => { state.count += 1; },

  },

  extraReducers: (builder) => {

    builder

      .addCase(fetchUser.pending, (state) => { state.loading = true; })

      .addCase(fetchUser.fulfilled, (state, action) => {

        state.user = action.payload;

        state.loading = false;

      });

  },

});

export const { increment } = appSlice.actions;

export default appSlice.reducer;

// app/providers.tsx + useSelector in components

RTK removes classic Redux boilerplate but still needs a store provider, typed hooks, and slice conventions — worth it when ten engineers touch the same state graph.

// components/UserPanel.tsx — RTK async usage

"use client";

import { useEffect } from "react";

import { useAppDispatch, useAppSelector } from "@/store/hooks";

import { fetchUser, increment } from "@/store/appSlice";

export function UserPanel() {

  const dispatch = useAppDispatch();

  const count = useAppSelector((s) => s.app.count);

  const user = useAppSelector((s) => s.app.user);

  const loading = useAppSelector((s) => s.app.loading);

useEffect(() => {

    dispatch(fetchUser());

  }, [dispatch]);

return (

    <div>

      <button onClick={() => dispatch(increment())}>Count: {count}</button>

      {loading ? <p>Loading…</p> : <p>{user?.name ?? "Guest"}</p>}

    </div>

  );

}

Same UX as the Zustand panel — more files, clearer audit trail in Redux DevTools when a bug report says "count jumped to 99 after refresh." That traceability is why enterprise codebases keep RTK despite smaller alternatives.

Bundle size comparison (approximate, gzipped)

// Measured on a minimal Next.js 15 client chunk (2026, rough)

// zustand@5 alone          ~ 1.2 kB gzip

// @reduxjs/toolkit + react-redux ~ 12–14 kB gzip

// Note: RTK buys DevTools, middleware patterns, large-team norms

Numbers vary with tree-shaking and what you import. For a marketing site with one modal flag, neither library may be necessary — React context or URL state is enough. For a data-heavy dashboard, 12 kB might be cheap compared to engineering consistency.

Before you optimise kilobytes, profile real user metrics — I document that workflow in Next.js performance case study. A 10 kB store library rarely matters next to an unvirtualised table or a chart library. Still, greenfield SPAs with tight mobile budgets in India often pick Zustand because every gram of JS counts on 4G.

10-criteria comparison table

Criteria	Zustand	Redux Toolkit
Learning curve	Low	Medium
Boilerplate	Minimal	Structured
DevTools	Plugin available	Excellent native
Middleware	Custom, light	Mature ecosystem
Async patterns	You write it	createAsyncThunk
Team scale	Small–medium	Medium–large
Next.js App Router	Client-only store	Client-only store
Selectors	Inline functions	reselect / createSelector
Testing	Easy store reset	Well-documented patterns
Hiring familiarity in India	Growing fast	Still very common

Before and after — prop drilling vs store

// BEFORE — theme passed through five layers

<Layout theme={theme} setTheme={setTheme}>

  <Sidebar theme={theme} setTheme={setTheme}>

    <Nav theme={theme} setTheme={setTheme} />

// AFTER — Zustand (or RTK) at leaves only

const theme = useAppStore((s) => s.theme);

const setTheme = useAppStore((s) => s.setTheme);

Do not reach for a global store because props are annoying once — reach when multiple distant trees share writable state that is not server data.

Server state is not Redux or Zustand

API lists, pagination, cache invalidation — use TanStack Query or Server Components + fetch with cache tags. I see teams stuff fetch results into Redux out of habit; that duplicates what Next.js already solves on public pages — see SSR vs SSG vs ISR.

My production setup

New dashboard in 2026: Zustand for UI chrome (sidebar, filters, wizard step). RTK when joining a legacy codebase that already exports slices and middleware. At my day job, the RTK codebase had time-travel debugging worth the bytes; greenfield internal tools get Zustand in under an hour.

Pair with RSC boundaries — stores are client-only; never import them into Server Components.

The single takeaway

Zustand for new small/medium apps; RTK for large coordinated teams. Measure bundle impact, but optimise for maintainability. Most state should stay local or on the server.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Tailwind CSS vs CSS Modules — What I Use in Production

Safdar Ali — Mon, 06 Jul 2026 18:30:00 +0000

Every new project sparks the same debate: utility classes or scoped CSS files? I ship Tailwind CSS on most Next.js marketing sites — including safdarali.in — but I still reach for CSS Modules when design tokens, animations, or designer handoff demand real stylesheets. This tailwind vs css modules comparison uses the same profile card in both approaches so you judge ergonomics, not different UIs.

Same component — Tailwind version

// components/ProfileCard.tsx

type Props = { name: string; role: string; avatarUrl: string };

export function ProfileCardTailwind({ name, role, avatarUrl }: Props) {

  return (

    <article className="flex gap-4 rounded-2xl border border-neutral-200 bg-white p-5 shadow-sm dark:border-white/10 dark:bg-neutral-900">

      <img

        src={avatarUrl}

        alt=""

        className="h-14 w-14 rounded-full object-cover ring-2 ring-neutral-200 dark:ring-white/20"

      />

      <div>

        <h3 className="font-semibold text-neutral-950 dark:text-white">{name}</h3>

        <p className="text-sm text-neutral-600 dark:text-neutral-400">{role}</p>

      </div>

    </article>

  );

}

No context switch — layout, colour, and dark mode sit on the JSX. Colocation is excellent when you iterate alone. Class strings get long on complex grids; I break into smaller components instead of one 200-character line.

On a Bengaluru startup landing page last quarter, the designer changed card padding three times in one sprint. With Tailwind I adjusted utilities in the same PR as copy changes — no hunting a separate CSS file. That speed is why I default to utilities for marketing. The tradeoff is readability in code review: reviewers must know common class names or rely on preview deploys.

Same component — CSS Modules version

// components/ProfileCard.module.css

.card {

  display: flex;

  gap: 1rem;

  padding: 1.25rem;

  border-radius: 1rem;

  border: 1px solid var(--border);

  background: var(--surface);

  box-shadow: 0 1px 2px rgb(0 0 0 / 0.06);

}

.avatar {

  width: 3.5rem;

  height: 3.5rem;

  border-radius: 9999px;

  object-fit: cover;

}

.name { font-weight: 600; }

.role { font-size: 0.875rem; color: var(--muted); }

// components/ProfileCard.tsx

import styles from "./ProfileCard.module.css";

export function ProfileCardModules({ name, role, avatarUrl }: Props) {

  return (

    <article className={styles.card}>

      <img src={avatarUrl} alt="" className={styles.avatar} />

      <div>

        <h3 className={styles.name}>{name}</h3>

        <p className={styles.role}>{role}</p>

      </div>

    </article>

  );

}

Designers reading Figma specs often prefer this — class names map to a stylesheet they can search. Theme variables live in one CSS file instead of duplicating dark: prefixes.

CSS Modules shine when you inherit a brand system documented as SCSS or plain CSS. I once joined a project where every spacing token lived in variables — rewriting into Tailwind would have taken weeks for zero user benefit. Modules let us wrap legacy styles with scoped class names while new React components shipped.

8-criteria comparison table

Criteria	Tailwind CSS	CSS Modules
Colocation with JSX	Excellent	Split files
Design system tokens	tailwind.config theme	CSS variables
Bundle size	Purged utilities (small)	Only used classes ship
Complex animations	Verbose in utilities	Natural in CSS
Onboarding juniors	Learn utility names	Learn CSS + scoping
Readable diffs	Long class strings	Cleaner CSS diffs
Third-party overrides	@apply or arbitrary	:global() when needed
Next.js default vibe	Very common	Built-in support

When Tailwind loses

Tailwind is not weak — it is the wrong tool when the stylesheet is the product. Long-form editorial layouts, printable invoices, and white-label themes where each tenant ships different CSS files are easier to reason about in modules or global layers than in thousands of arbitrary utility strings.

Keyframe-heavy animations — staggered reveals and complex hover chains read better in a module file. Print stylesheets — Tailwind can do it; CSS is clearer. Legacy design systems already documented in SCSS variables — rewriting into utilities is waste. Highly bespoke art-directed pages where every section has unique spacing not in your token scale — fighting arbitrary values is slower than writing CSS.

/* ProfileCard.module.css — animation Tailwind would fight */

@keyframes riseIn {

  from { opacity: 0; transform: translateY(12px); }

  to { opacity: 1; transform: translateY(0); }

}

.cardAnimated {

  animation: riseIn 0.4s ease-out both;

}

Migrating styles — before and after

// BEFORE — global CSS leaked into production

.button {

  background: blue;

}

// Every <button> on the site turned blue

// AFTER — CSS Modules scope automatically

// Button.module.css

.root { background: var(--brand); }

// Only <button className={styles.root}>

Tailwind avoids global leakage differently — utilities are atomic. Both beat unstructured global CSS from 2018 Create React App projects.

The hybrid I use on client sites

In production: Tailwind for layout, spacing, typography, responsive grids. CSS Modules (or a single globals.css) for animations, rare third-party overrides, and print rules. On a recent marketing rebuild, that split kept Lighthouse CSS payload small while designers still got a module for the hero animation — details in performance case study.

My production setup

Default stack: Next.js + TypeScript strict + Tailwind + cn() helper for conditional classes. I add modules per feature folder when a component accrues more than ~15 lines of custom CSS. At my day job, we banned new global selectors except resets.

Neither choice fixes bad component architecture — see Next.js folder structure guide for how I colocate styles with features.

I also run Prettier with the Tailwind class sorter plugin on teams that use utilities — consistent order makes long class strings diff cleanly. CSS Module projects get stylelint for nesting and variable naming instead.

The single takeaway

Tailwind for speed; CSS Modules for complexity. Pick per component, not per religion. Same card, two implementations — choose the file you will actually maintain six months from now.

Interview tip I give juniors in India: neither answer is wrong in isolation. Ask what the team already uses, whether designers pair with you daily, and whether the page is marketing or a long-lived dashboard. Match the toolchain to the delivery cadence, not Twitter polls.

Related: Projects. Contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

React 19 Features — What Actually Changed and What I Use

Safdar Ali — Sun, 05 Jul 2026 18:30:00 +0000

React 19 shipped a laundry list of features. Twitter threads treated every hook like mandatory. In production on client sites and this portfolio, I adopted a subset — the ones that remove real bugs or UX jank — and ignored the rest until the ecosystem caught up. This is my honest react 19 features guide: what changed, code you can paste, and what I am still waiting on.

What actually changed at a high level

React 19 stabilised the Actions model (forms and mutations with pending state), added useOptimistic for instant UI feedback, introduced the use() hook for reading promises and context, improved hydration error messages, and made ref-as-prop cleaner. The compiler (React Forget) is separate — exciting, not required to upgrade.

Upgrade path: Next.js 15 projects already pin compatible React versions. Read RSC vs client components before mixing Actions with Server Components — boundaries still matter.

React 19 hooks and APIs — quick reference table

API	Purpose	Client / Server	I use in prod?
useOptimistic	Optimistic UI while mutation runs	Client	Yes
use()	Read promise or context	Both (with Suspense)	Yes (with RSC)
useActionState	Form action state	Client	Yes
useFormStatus	Pending from parent form	Client	Yes
ref as prop	No forwardRef boilerplate	Both	Gradual
Document metadata	title, meta in components	Client (limited)	Prefer Next.js metadata

useOptimistic — instant feedback without lying to the user forever

Cart quantity updates, like buttons, todo toggles — users expect instant UI. useOptimistic shows the next state while the server catches up, then reconciles on success or rolls back on error.

"use client";

import { useOptimistic, useTransition } from "react";

import { updateQuantity } from "./actions";

type Item = { id: string; qty: number };

export function CartLine({ item }: { item: Item }) {

  const [optimisticQty, setOptimisticQty] = useOptimistic(item.qty);

  const [isPending, startTransition] = useTransition();

function changeQty(next: number) {

    startTransition(async () => {

      setOptimisticQty(next);

      await updateQuantity(item.id, next);

    });

  }

return (

    <div>

      <button onClick={() => changeQty(optimisticQty + 1)} disabled={isPending}>

        +

      </button>

      <span>{optimisticQty}</span>

    </div>

  );

}

// BEFORE — manual optimistic state with footguns

const [qty, setQty] = useState(item.qty);

const [pending, setPending] = useState(false);

async function bump() {

  const prev = qty;

  setQty(qty + 1); // optimistic

  setPending(true);

  try {

    await updateQuantity(item.id, qty + 1);

  } catch {

    setQty(prev); // easy to forget rollback paths

  } finally {

    setPending(false);

  }

}

// AFTER — useOptimistic + transition: rollback wired correctly

use() — promises and context without useEffect hacks

// Server Component passes a promise to client child

import { use } from "react";

type Product = { id: string; name: string };

function ProductList({ productsPromise }: { productsPromise: Promise<Product[]> }) {

  const products = use(productsPromise); // suspends until resolved

  return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name}</li>

      ))}

    </ul>

  );

}

// Parent (Server Component) creates the promise once

export default function Page() {

  const productsPromise = getProducts(); // do not await here

  return (

    <Suspense fallback={<p>Loading products…</p>}>

      <ProductList productsPromise={productsPromise} />

    </Suspense>

  );

}

In production I use use() with Server Components streaming data — same mental model as async server fetch, less client useEffect spaghetti.

Actions and forms — less boilerplate than manual fetch

"use client";

import { useActionState } from "react";

import { subscribe } from "./actions";

export function NewsletterForm() {

  const [state, formAction, pending] = useActionState(subscribe, { ok: false, message: "" });

return (

    <form action={formAction}>

      <input name="email" type="email" required />

      <button disabled={pending}>{pending ? "Sending…" : "Subscribe"}</button>

      {state.message && <p>{state.message}</p>}

    </form>

  );

}

Pair with Next.js Server Actions for mutations without a separate API route file — still validate on the server, still treat client state as untrusted.

What I immediately adopted

useOptimistic on any user-facing mutation where latency is felt on Indian mobile networks. useActionState / useFormStatus on marketing forms — fewer lines than custom pending flags. use() with Suspense boundaries on catalog sections fed from server promises. Better hydration errors — saved me an hour debugging a client-only chart imported into a Server Component (fixed by splitting the leaf).

// ref as prop — dropped forwardRef on new components

type ButtonProps = React.ComponentProps<"button"> & { ref?: React.Ref<HTMLButtonElement> };

export function Button({ ref, ...props }: ButtonProps) {

  return <button ref={ref} {...props} />;

}

What I'm waiting on

React Compiler (Forget) — I will enable it per-route after stable Next.js integration docs, not on day one of React 19. Document metadata in client trees — I still use Next.js generateMetadata for SEO. Full ecosystem typings — some third-party libs lagged React 19 types for weeks; I pinned versions until they caught up.

I am also not rewriting every forwardRef component overnight — new code uses ref-as-prop; old code migrates on touch.

Waiting is a strategy, not laziness. The compiler will change how much manual memo we write — see my useCallback vs useMemo guide for why I am not adding more memo hooks while the ecosystem catches up.

My production setup

In production: React 19 + Next.js 15, Server Components by default, React 19 Actions on forms that need pending UX, optimistic updates on commerce interactions. Performance work still lives in caching and bundle size — see Next.js performance case study.

When experimenting, I use the workflow in Cursor + Claude for React — AI suggests React 19 APIs quickly, but I verify against official release notes before merge.

The single takeaway

React 19 is not a rewrite mandate. Adopt optimistic UI, Actions, and use() where they solve problems you already have. Wait on compiler and metadata experiments until your stack documents them.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

SSR vs SSG vs ISR in Next.js — Plain English Explanation

Safdar Ali — Sun, 05 Jul 2026 15:42:29 +0000

I'm Safdar Ali. For six months I treated every Next.js page like SSR because "server" sounded safest. Marketing pages were slower than they needed to be; dashboard pages were over-cached. SSR vs SSG in Next.js is not a popularity contest — it is a delivery choice: when HTML is built, how often it refreshes, and who pays the compute bill. This article is the plain-English map I wish I had, with code for all three modes and a flowchart you can screenshot.

Three acronyms, one question: when is HTML built?

SSR (Server-Side Rendering) builds HTML on each request (or per-request cache miss). Fresh data, higher server load.

SSG (Static Site Generation) builds HTML at deploy time. Fastest CDN delivery; stale until you redeploy unless you add revalidation.

ISR (Incremental Static Regeneration) is SSG plus background refresh — static speed with a TTL. In App Router this is mostly fetch with next.revalidate.

// Mental model — same page, three delivery timings

// SSG:  HTML built at deploy ──────────────────► CDN serves file

// ISR:  HTML built at deploy ──► stale ──► regen in background after N sec

// SSR:  HTML built when user hits URL ─────────► server sends fresh HTML

None of these replace React. They describe when your React tree becomes HTML the browser can paint before hydration.

Decision flowchart — which mode to pick

                    START: New Next.js page

                              |

                              v

                    Does Google need HTML

                    with real content on

                    first request?

                         /        \

                       NO          YES

                       |            |

                       v            v

              Authenticated      Is data identical

              dashboard / SPA?   for all users?

                    |                 /      \

                   YES               NO      YES

                    |                |        |

                    v                v        v

            "use client" +       SSR or      Changes

            client fetch         per-user    every hour+

            (no SSR win)         data?          /    \

                                /    \        NO    YES

                              YES    NO        |      |

                               |      |        v      v

                               v      v       SSG    ISR

                              SSR   ISR      (rare) (revalidate)

                                    or SSG

                                    + short

                                    revalidate

Print that flowchart. When you are unsure, default marketing to ISR with a sensible revalidate, default logged-in dashboards to client rendering.

SSG — build once, serve from the edge

Use SSG for pages where data changes only when you deploy — legal pages, about pages, rarely updated landing heroes.

// app/about/page.tsx — static by default (no fetch cache opts)

export default function AboutPage() {

  return (

    <main>

      <h1>About Safdar Ali</h1>

      <p>Frontend engineer, Bengaluru — available for React / Next.js work.</p>

    </main>

  );

}

// Dynamic routes can still be SSG if you export generateStaticParams

export async function generateStaticParams() {

  const slugs = await getAllBlogSlugs();

  return slugs.map((slug) => ({ slug }));

}

Tradeoff: a price change on an e-commerce SKU list will not appear until redeploy or ISR kicks in. For truly static content, that is a feature — zero origin load.

ISR — static speed, controlled freshness

// app/products/page.tsx — ISR via fetch revalidate (App Router)

type Product = { id: string; name: string; price: number };

async function getProducts(): Promise<Product[]> {

  const res = await fetch("https://api.example.com/products", {

    next: { revalidate: 3600 }, // ISR: refresh at most every hour

  });

  if (!res.ok) throw new Error("Failed to load products");

  return res.json();

}

export default async function ProductsPage() {

  const products = await getProducts();

  return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name} — ₹{p.price}</li>

      ))}

    </ul>

  );

}

First visitor after TTL might still see stale HTML while regeneration runs — acceptable for catalog pages, unacceptable for live stock tickers. Know your freshness requirement before picking ISR.

SSR — per-request HTML when data must be fresh

// app/dashboard/summary/page.tsx — SSR: no cache on fetch

async function getSummary(userId: string) {

  const res = await fetch("https://api.example.com/summary/" + userId, {

    cache: "no-store", // SSR — always fresh for this user

  });

  return res.json();

}

export default async function SummaryPage() {

  const session = await getSession();

  const summary = await getSummary(session.userId);

  return <SummaryClient data={summary} />;

}

SSR costs more at scale. Use it when personalisation or real-time correctness beats CDN economics — not because "server sounds professional."

SSR vs SSG vs ISR — comparison table

Criteria	SSG	ISR	SSR
When HTML is built	Deploy time	Deploy + periodic regen	Each request
TTFB on CDN	Fastest	Fast (often cached)	Slower
Data freshness	Stale until deploy	TTL-based	Real-time
Server cost	Lowest	Low–medium	Highest
SEO	Excellent	Excellent	Excellent
Per-user data	Poor fit	Poor fit	Good fit
App Router signal	Default static page	revalidate: N	cache: no-store

Marketing site vs dashboard — what I actually ship

Marketing site (public, SEO, shared content): ISR for blog and product listings, SSG for about/legal, Server Components for HTML. On a client rebuild I moved the blog to revalidate: 86400 and saw origin requests drop 70% — part of the story in my Next.js performance case study.

Dashboard (authenticated, personal): client components, SWR or WebSockets, no ISR fantasy. Trying to ISR user-specific charts is how teams waste a sprint.

// BEFORE — marketing page forced to SSR "just because"

export default async function PricingPage() {

  const plans = await fetch("https://api.example.com/plans", { cache: "no-store" });

  // Every visitor hits origin — same JSON for everyone

}

// AFTER — ISR: shared plans, CDN-friendly

export default async function PricingPage() {

  const res = await fetch("https://api.example.com/plans", { next: { revalidate: 3600 } });

  const plans = await res.json();

  // ...

}

My production setup

In production I label routes in file comments — ISR 1h or SSR session — so the next developer does not "optimise" a dashboard into ISR by accident. Pair this with RSC vs client components — rendering mode and component boundary are two separate decisions.

At my day job, the mistake I see most is SSR everywhere because the team learned Pages Router getServerSideProps first. App Router caching is more granular — use it.

The single takeaway

Pick rendering by freshness and audience, not acronym prestige. Marketing: ISR + SSG. Dashboards: client. Personalised SSR only when you mean it.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

TypeScript Strict Mode — Why I Use It in Every Project

Safdar Ali — Sun, 05 Jul 2026 14:07:05 +0000

I'm Safdar Ali, a frontend engineer in Bengaluru. Three years ago I turned off strict mode on a client dashboard because the migration felt noisy. Two weeks later, a user with an empty profile name crashed the settings page in production — exactly the class of bug strictNullChecks would have flagged at compile time. Since then, typescript strict mode is non-negotiable on every React and Next.js repo I touch. This guide is the tsconfig I copy, the flags I care about, and the errors that actually save you hours.

What "strict mode" actually means in TypeScript

Strict mode is not one switch — it is a family of compiler checks bundled under strict: true in tsconfig.json. When enabled, TypeScript refuses code that relies on implicit any, unchecked null access, or loose function types.

The tradeoff is upfront friction: your first week on an old JavaScript codebase will surface hundreds of errors. The payoff is fewer 2am Slack messages and safer refactors when you rename a prop across forty components.

// tsconfig.json — baseline I paste into new Next.js projects

{

  "compilerOptions": {

    "target": "ES2017",

    "lib": ["dom", "dom.iterable", "esnext"],

    "allowJs": true,

    "skipLibCheck": true,

    "strict": true,

    "noEmit": true,

    "esModuleInterop": true,

    "module": "esnext",

    "moduleResolution": "bundler",

    "resolveJsonModule": true,

    "isolatedModules": true,

    "jsx": "preserve",

    "incremental": true,

    "plugins": [{ "name": "next" }],

    "paths": { "@/": ["./"] }

  },

  "include": ["next-env.d.ts", "/*.ts", "/.tsx", ".next/types//.ts"],

  "exclude": ["node_modules"]

}

strict: true turns on strictNullChecks, noImplicitAny, and several related flags. You can enable them individually, but I have never found a good reason to run half-strict on a greenfield app.

Strict flags — what each one does

Flag	Catches	Pain level
strictNullChecks	null / undefined used as values	High on legacy APIs
noImplicitAny	Parameters without types	Medium
strictFunctionTypes	Unsafe callback assignments	Low–medium
strictBindCallApply	Wrong bind/call/apply args	Low
noImplicitThis	Ambiguous this in functions	Low
alwaysStrict	Emits "use strict" per file	None
useUnknownInCatchVariables	catch (e) typed as any	Low

If you are migrating an old repo, enable flags one at a time in CI — fix noImplicitAny first, then strictNullChecks. That order reduces the simultaneous error flood.

The 3 errors strict mode catches most often

After dozens of code reviews, these three patterns account for most of the bugs strict mode prevented before merge — not theoretical type pedantry, real user-facing failures.

1. Possibly undefined property access

type User = { id: string; displayName?: string };

function greet(user: User) {

  // Error under strictNullChecks: 'displayName' is possibly 'undefined'

  return "Hello, " + user.displayName.toUpperCase();

}

// Fix — narrow before use

function greetSafe(user: User) {

  const name = user.displayName ?? "Guest";

  return "Hello, " + name.toUpperCase();

}

2. Implicit any on event handlers

// BEFORE — noImplicitAny flags the parameter

function handleChange(e) {

  setQuery(e.target.value);

}

// AFTER — explicit React type

import type { ChangeEvent } from "react";

function handleChange(e: ChangeEvent<HTMLInputElement>) {

  setQuery(e.target.value);

}

3. Wrong API response shape assumed

type ApiOrder = { id: string; total: number; discount?: number };

async function getOrder(id: string): Promise<ApiOrder> {

  const res = await fetch("/api/orders/" + id);

  return res.json();

}

function OrderSummary({ order }: { order: ApiOrder }) {

  // strictNullChecks: discount may be undefined

  const saved = order.discount ?? 0;

  return <p>Total: ₹{order.total - saved}</p>;

}

Number three is why I type API responses at the boundary — not inside every child component. One wrong assumption on fetch results propagates silently without strict types.

The production bug strict mode would have caught

At my day job, a checkout helper read user.address.line2 without checking if address existed. Indian users who signed up with phone-only onboarding had address: null. The page white-screened on submit.

// BEFORE — passed review, failed in production

type User = { id: string; address: { line1: string; line2?: string } | null };

function formatShipping(user: User) {

  return user.address.line1 + ", " + user.address.line2;

}

// AFTER — compiler forces the guard

function formatShipping(user: User) {

  if (!user.address) return "Address required";

  const line2 = user.address.line2 ?? "";

  return user.address.line1 + (line2 ? ", " + line2 : "");

}

We added the guard in a hotfix. With strict null checks enabled from day one, the first version would never have compiled. That single incident paid for every strict migration I have done since.

Migrating a component — before and after strict

// BEFORE — loose props, any sneaks in

export function ProductCard(props) {

  const { title, price, onAdd } = props;

  return (

    <button onClick={() => onAdd(title)}>

      {title} — ₹{price}

    </button>

  );

}

// AFTER — explicit contract

type ProductCardProps = {

  title: string;

  price: number;

  onAdd: (title: string) => void;

};

export function ProductCard({ title, price, onAdd }: ProductCardProps) {

  return (

    <button onClick={() => onAdd(title)}>

      {title} — ₹{price}

    </button>

  );

}

The after version is longer by four lines. It is also grep-friendly: rename a prop and TypeScript lists every broken callsite instead of leaving undefined at runtime.

Strict mode with Next.js App Router

Next.js 15 projects ship with TypeScript by default. Server Components add one wrinkle: props and params are often Promise-wrapped. Strict typing there prevents awaiting the wrong shape.

// app/blog/[slug]/page.tsx

type PageProps = { params: Promise<{ slug: string }> };

export default async function BlogPostPage({ params }: PageProps) {

  const { slug } = await params;

  const post = await getPost(slug);

  if (!post) return null;

  return <Article post={post} />;

}

Pair strict TypeScript with Server Components discipline from my RSC vs client components guide — types tell you what runs where; boundaries tell you what ships to the browser.

When I temporarily relax a rule (rarely)

Third-party libraries with broken types sometimes need @ts-expect-error on one line — not strict: false for the whole project. I also use skipLibCheck: true so node_modules type noise does not block builds — that is standard, not cheating.

// Scoped escape — document why

// @ts-expect-error legacy chart lib ships wrong types until v4

<LegacyChart data={metrics} />

What I do not do: disable strict for "speed." Typing saves more calendar time than it costs once the team is past the first migration week.

My production setup

In production I run strict: true, ESLint @typescript-eslint/recommended, and tsc --noEmit in CI before every merge. On this portfolio and client marketing sites, that combo caught unused env vars and wrong metadata types before they hit Vercel.

When I use AI-assisted refactors, I still read the diff — see my Cursor + Claude workflow — but TypeScript strict mode is the safety net when autocomplete hallucinates a prop name.

Junior developers in Bengaluru often ask if strict is "for senior devs." It is the opposite: strict mode teaches you the shape of data before runtime teaches you with user complaints.

The single takeaway

TypeScript strict mode is cheap insurance. Turn it on in tsconfig.json, fix errors in order, and let the compiler catch null access, implicit any, and API drift before your users do.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Next.js vs React — Which Should You Learn First in 2026?

Safdar Ali — Sun, 05 Jul 2026 13:44:22 +0000

I'm Safdar Ali, a frontend engineer in Bengaluru. Last month a junior dev on LinkedIn asked me the same question I heard in 2022, 2024, and again this week: "Should I learn React or jump straight to Next.js?" After four years shipping both — marketing sites, dashboards, and this portfolio on safdarali.in — my answer is not "always Next.js." It's learn React first, then Next.js fast. Here's why, with code you can paste today.

React and Next.js are not the same thing — stop comparing them like they are

React is a UI library. It handles components, state, and rendering. It does not ship routing, data fetching conventions, or a production server model out of the box.

Next.js is a React framework. It sits on top of React and adds file-based routing, server rendering, image optimisation, and deployment defaults. When people search "nextjs vs react 2026," they usually mean "plain React + Vite" vs "Next.js App Router."

The tradeoff is clear: React alone gives you control. Next.js gives you speed to production — if you already understand what React is doing under the hood.

Think of it like driving. React is learning how an engine, steering, and brakes work. Next.js is a car that already has those parts assembled — plus GPS, airbags, and a service schedule. You can build a car from parts (React + Vite + React Router + your own SSR layer). Most product teams in 2026 don't — they buy the assembled car and focus on where they're going.

That analogy breaks if you don't know what an engine is. Jump into Next.js without JSX, props, or state fundamentals and every error message feels like framework magic instead of JavaScript.

Same feature, two stacks — a product list page side by side

Take a simple product list: fetch data, render cards, link to detail pages. Here's the split between a typical React + client fetch setup and Next.js App Router with a Server Component.

React (Vite + client fetch) — you wire everything

// src/pages/ProductList.tsx — runs in the browser only

import { useEffect, useState } from "react";

type Product = { id: string; name: string; price: number };

export function ProductList() {

  const [products, setProducts] = useState<Product[]>([]);

  const [loading, setLoading] = useState(true);

useEffect(() => {

    // SEO problem: crawlers see empty HTML until JS runs

    fetch("/api/products")

      .then((res) => res.json())

      .then(setProducts)

      .finally(() => setLoading(false));

  }, []);

if (loading) return <p>Loading…</p>;

return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name} — ₹{p.price}</li>

      ))}

    </ul>

  );

}

Next.js App Router — server fetch, less client JS

// app/products/page.tsx — Server Component by default

type Product = { id: string; name: string; price: number };

async function getProducts(): Promise<Product[]> {

  const res = await fetch("https://api.example.com/products", {

    next: { revalidate: 3600 }, // ISR-style cache — fresh enough for catalog pages

  });

  if (!res.ok) throw new Error("Failed to load products");

  return res.json();

}

export default async function ProductsPage() {

  const products = await getProducts();

// HTML arrives with content — better LCP, better SEO

  return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name} — ₹{p.price}</li>

      ))}

    </ul>

  );

}

Same UI. Different delivery model. On a client marketing site I migrated to App Router, that shift alone contributed to LCP dropping from 4.2s to 1.7s — I break down the full stack in my Next.js performance case study.

With the React version, you also own routing. You'd add React Router, configure a layout wrapper, and probably a loading skeleton component. None of that is hard — it's just three extra files before you write business logic. Next.js collapses routing into folder names: app/products/page.tsx is both the route and the page. After four years of shipping React, that convention still saves me time on every new project.

The React approach wins when your API is a separate team's problem and you only care about the browser. Next.js wins when HTML on first request matters — SEO, social previews, slow 4G in tier-2 Indian cities.

Next.js vs React — 10 criteria compared

Criteria	React (Vite / CRA-style)	Next.js (App Router)
What it is	UI library	Full React framework
Routing	You add React Router	File-based, built in
SEO / first paint	CSR unless you add SSR	SSR, SSG, ISR native
Data fetching	useEffect + fetch (client)	async Server Components
Learning curve	Lower entry, higher assembly	Steeper, fewer decisions later
Bundle size control	You own the whole graph	RSC reduces client JS by default
Deployment	Static host + separate API	Vercel/Node edge-ready
Best for SPAs	Excellent	Works, often overkill
Best for marketing / content sites	Extra work	Excellent
Job market in India (2026)	Still required everywhere	Listed on most product roles

Takeaway: React teaches you the language. Next.js teaches you how product teams ship that language at scale.

Neither row is a knockout punch. The job market row matters in India — recruiters still filter on "React" in CVs, but product job descriptions increasingly say "Next.js" or "React with SSR experience." Learning both in sequence covers either filter without lying on your resume.

When plain React still wins

I still reach for React without Next.js when the app is a true SPA — authenticated dashboards, internal tools, or embeddable widgets inside another product. No SEO requirement, no server HTML, no file-based routing benefit.

// When this is your whole app, Next.js adds ceremony you won't use:

// - Single route shell

// - Auth gate on the client

// - WebSocket or polling for live data

export function AnalyticsDashboard() {

  // 100% client-side — Server Components buy you nothing here

  return <LiveChart streamUrl="/ws/metrics" />;

}

What nobody tells you is that forcing App Router patterns onto a dashboard can slow you down — you fight the framework instead of shipping features.

// BEFORE — over-engineered dashboard page in Next.js

export default async function DashboardPage() {

  const session = await getServerSession(); // re-fetch every navigation

  const metrics = await fetchMetrics(session.userId);

  return <DashboardClient initial={metrics} />; // still hydrates everything

}

// AFTER — honest SPA inside Next.js (or plain React if you prefer)

"use client";

export default function DashboardPage() {

  const metrics = useLiveMetrics(); // WebSocket / SWR — belongs on client

  return <DashboardClient metrics={metrics} />;

}

I've shipped internal analytics tools as Create React App SPAs that ran for years without a rewrite. The users were logged-in employees on fast office networks — SEO was irrelevant. Pick the stack that matches the delivery model, not the hype cycle.

When Next.js is the obvious pick in 2026

Public websites, blogs, e-commerce, landing pages, anything that needs Google to see real HTML on first request. Also any full-stack product where API routes and server actions live next to UI — one repo, one deploy.

If you're building like the client sites in my portfolio— marketing-first, performance-sensitive, mobile-heavy — Next.js is the default I recommend in 2026.

// app/products/[slug]/page.tsx — metadata + SSR in one file

import type { Metadata } from "next";

type Props = { params: Promise<{ slug: string }> };

export async function generateMetadata({ params }: Props): Promise<Metadata> {

  const { slug } = await params;

  const product = await getProduct(slug);

  return {

    title: product.name + " — Shop",

    description: product.summary, // Google + WhatsApp previews use this

    openGraph: { images: [product.imageUrl] },

  };

}

export default async function ProductPage({ params }: Props) {

  const { slug } = await params;

  const product = await getProduct(slug);

  return <ProductDetail product={product} />;

}

Try doing that cleanly in a client-only React app. You can — with react-helmet, a meta tag library, and probably a pre-render step — but you're rebuilding what Next.js ships on day one. For public pages, that assembly tax adds up across every route.

What I'd choose if starting today

Week 1–4: React fundamentals — components, props, state, effects, lists, forms. Build small UI without a framework. I cover this path on my YouTube channel — 70+ free tutorials aimed at developers in India learning their first production stack.

Week 5–8: TypeScript basics, then Next.js App Router — one page, one layout, one Server Component fetch. Read my RSC vs client components guide before you sprinkle "use client" everywhere.

Month 3: Ship one real project — portfolio, blog, or small product — deploy to Vercel. Employers don't hire tutorial completers. They hire people who shipped.

Free resources that worked for me: official React docs (beta.react.dev), Next.js learn course, and building in public on GitHub. Paid is optional until you need structured accountability — a ₹2,000 Udemy course is fine; a ₹2 lakh bootcamp is not required to land a first frontend role in India if your GitHub shows real work.

If you only have time for one thing this month: learn React. If you have two: add Next.js immediately after — not instead.

Does React 19 change the nextjs vs react 2026 decision?

React 19 stabilised features that used to be Next.js-only experiments — improved hydration, the use() hook, and better form actions. That does not make Next.js optional. It makes React itself more capable while Next.js still owns routing, caching, and deployment.

// React 19 — use() for promises inside components (still client or RSC)

import { use } from "react";

function ProductList({ productsPromise }: { productsPromise: Promise<Product[]> }) {

  const products = use(productsPromise); // suspends until resolved

  return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name}</li>

      ))}

    </ul>

  );

}

You can learn this API in a plain React sandbox. In production, I still reach for Next.js to wire the promise on the server and stream HTML. The library got sharper; the framework still saves calendar time.

Takeaway: React 19 is a reason to learn modern React, not a reason to skip Next.js on public web apps.

My production setup

In production I default to Next.js App Router with TypeScript strict mode, Tailwind CSS, and Server Components for anything public-facing. Client components are leaves — charts, modals, forms — not entire pages.

On a recent marketing rebuild, that discipline plus next/image and route caching moved Lighthouse performance from 54 to 91. The bundle analyser showed 38% less client JavaScript after we moved data fetching to the server — same pattern I document in the performance case study linked above.

Plain React stays in my toolbox for isolated widgets and legacy SPAs. Next.js is where I ship anything a user or crawler hits on the open web.

When I interview junior candidates in Bengaluru, I ask them to explain one component they wrote — props in, state updates, why a list needs keys. I don't start with middleware or ISR. If they learned only Next.js templates, they often cannot answer. If they learned React first, the Next.js-specific questions become teachable in a week.

The mistake I see most often

Beginners skip React and copy-paste Next.js templates. They can deploy, but they cannot debug hydration errors, cannot explain why a component is client-only, and panic when the build fails on server/client boundaries.

// BEFORE — copied from a template, broken mental model

"use client";

export default function Page() {

  useEffect(() => {

    fetch("/api/data").then(/* ... */); // could be server-side

  }, []);

}

// AFTER — fetch on server, interactivity only where needed

export default async function Page() {

  const data = await getData(); // runs once on server

  return <ProductGrid data={data} />;

}

Learn React so the second snippet feels natural — not magic.

Bootcamps that advertise "Full Stack Next.js in 4 weeks" without JSX fundamentals produce developers who can clone a Vercel deploy — until the first production bug. I'd rather you ship one ugly React todo app you fully understand than a polished template you cannot modify.

The single takeaway

Next.js vs React in 2026 is the wrong either/or. React is the skill. Next.js is how most product teams apply that skill on the web. Learn React first, ship one Next.js project second, and measure everything — LCP, bundle size, time-to-first-commit.

I still get DMs asking which certificate to buy. Buy none until you've built something. Certificates prove attendance; GitHub repos prove competence. Start with React this week, add Next.js next month, and publish the result — even if it's rough.

Related reading: How I cut load time by 60% with Next.js App Router. More case studies: safdarali.in/projects. Questions: safdarali.in/contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

DEV Community: Safdar Ali

How AI Changed the Way I Write React Code — 2 Years In

What actually changed in my daily work

What did not change — and probably never will

Skills that matter more now — ranked honestly

Before and after — same feature, two eras

What this means if you are learning React in India

Mistakes I made adopting AI too fast

My weekly rhythm with AI in 2026

Where ai react development goes from here

The single takeaway

Related reading

Vibe Coding in 2026 — Is It Real or Just a Trend?

Free Video Thumbnail Generator Online — No Upload

Jev Is Not an LLM. That Is the Point.

What you are actually calling

Put the question on the type, not in the prompt

Confidence is the part you branch on

Where it fits, and where it does not

A small architecture, not a new model in every slot

☕ If This Helped You

Next.js App Router Complete Beginner Guide 2026

Mental model — folders are routes

Step 1 — Root layout (HTML shell once)

Step 2 — First page

Step 3 — loading.tsx for perceived speed

Step 4 — Server Component fetch (no useEffect)

App Router files — quick comparison table

Step 5 — Add client components only as leaves

Step 6 — Dynamic routes and params

Learning path after this guide

My production setup

The single takeaway

Related reading

Free Video Thumbnail Generator Online — No Upload

Why Your Next.js 15 App is Still Slow (And How to Fix the React 19 Hydration Lag)

WCAG 2.2 Accessibility for React Developers — Practical Guide

How I Structure Large Next.js Projects — Folder Architecture Guide

Real folder tree — production-shaped layout

Why each folder exists

Thin pages — route files under 40 lines

The 10-second findability rule

First project mistakes I made

Route groups for different shells

Path aliases and import direction

My production setup

The single takeaway

Related reading

How to Build a Frontend Developer Portfolio That Stands Out

React Server Components vs Client Components — When to Use Which

React useCallback vs useMemo — When You Actually Need Them

What each hook actually does

The over-memoising mistake I made

How I use the React Profiler

When to use which — table

useCallback — legitimate use with memoised child

useMemo — filtering large lists

Rule of thumb I teach in reviews

My production setup

The single takeaway

Related reading

How to Build a Frontend Developer Portfolio That Stands Out

React Server Components vs Client Components — When to Use Which

Zustand vs Redux Toolkit — Which State Manager in 2026?

Zustand — counter and async fetch

Redux Toolkit — same features, more structure

Bundle size comparison (approximate, gzipped)

10-criteria comparison table

Before and after — prop drilling vs store

Server state is not Redux or Zustand

My production setup

The single takeaway

Related reading

Tailwind CSS vs CSS Modules — What I Use in Production

Free Video Thumbnail Generator Online — No Upload

Tailwind CSS vs CSS Modules — What I Use in Production

Same component — Tailwind version

Same component — CSS Modules version

8-criteria comparison table

When Tailwind loses