DEV Community: Safdar Ali

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.

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.

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.

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

I Built a Free Video Thumbnail Generator That Never Uploads Your Files

Safdar Ali — Sun, 07 Jun 2026 00:01:42 +0000

Every creator hits the same wall: you finished the video, exported the MP4, uploaded to YouTube — and forgot the custom thumbnail.

Your best frame is already inside that file. You just need to grab it.

Most online tools make you upload the entire video to their server. That is slow for large files, risky for unreleased content, and often ends with a watermark unless you pay.

So I built FrameSnap — a free browser tool that extracts thumbnails locally. No account. No watermark. Your video never leaves your device.

The problem with "free" thumbnail tools

Search for free video thumbnail generator online and you get dozens of results. Most fall into two camps:

Server-upload converters — your file goes to their cloud, gets processed, comes back with a logo on the free tier.
Design apps — great for templates and text overlays, overkill when you already have a strong frame in your footage.

Creators actually need something simpler:

Scrub to the right moment
Export at 1280×720 for YouTube
Download PNG or JPG
Optionally grab 6–25 frames to compare before deciding
Do it without sending client footage to a random SaaS

That last point matters if you record courses, agency work, or anything under NDA.

Why client-side wins here

Modern browsers can decode MP4, WebM, and MOV through the <video> element. The Canvas API can draw any frame to a bitmap. Download via blob URL. Done.

The flow in FrameSnap:

User selects file → video loads in memory → set currentTime → drawImage to canvas → export PNG/JPG

No API route handles the video. No S3 bucket. No queue.

Trade-offs I accepted:

Works great	Does not work
Local MP4, WebM, MOV, MKV	YouTube watch-page URLs (platform blocks direct access)
Direct `.mp4` URLs	DRM-protected streams
Batch export via auto-snap intervals	Replacing Photoshop for layered design

For the 80% case — "I have an exported MP4 and need a still" — client-side is faster and more private than upload-and-wait.

Features I cared about as a user

These shaped the product more than any framework choice:

Auto-snap presets — Quick 6 frames, or every 2%/4%/5% of video length. Picking one thumbnail from a 15-minute video by manual scrubbing is painful.

Download all as ZIP — Compare candidates side-by-side before adding text in Canva.

Original aspect ratio — Portrait video stays portrait. No black bars from forcing everything into 16:9.

JPG quality slider — YouTube's custom thumbnail limit is 2 MB. PNG screen recordings blow past that; JPG at 90% usually does not.

Direct MP4 URL tab — If your file is hosted at https://yoursite.com/demo.mp4, paste and go. Not a Google Drive preview link — an actual file URL.

Stack (for the curious)

Next.js 16 — App Router, static blog with scheduled publishing
TypeScript — the fun part is typed canvas math, not the boilerplate
Canvas + HTML5 Video — frame capture
JSZip — batch downloads
Vercel — deploy at framesnap.safdarali.in

100% client-side processing. The server only serves HTML/JS.

Try it

👉 framesnap.safdarali.in

Drop an MP4 (or paste a direct video URL)
Scrub or use auto-snap
Export HD (1280×720) PNG/JPG
Upload to YouTube Studio

I also wrote a longer comparison guide on the site: Free Video Thumbnail Generator Online.

What's next

More export presets for Shorts/Reels covers
Keyboard shortcuts for power users
Better error messages for codec edge cases

If you try it and it saves you ten minutes before your next upload, that is enough for me.

Support the project

FrameSnap is free with no export limits. If it helps your workflow, you can buy me a coffee ☕ — it keeps side projects like this alive.

Built by Safdar Ali. Feedback welcome in the comments — especially if you hit a codec or browser edge case I have not seen yet.

How to Build a Frontend Developer Portfolio That Stands Out

Safdar Ali — Sun, 31 May 2026 23:00:00 +0000

I rebuilt safdarali.in on Next.js as a living document — not a static PDF, but a frontend developer portfolio that shows how I think about performance, content, and craft.

Fast first paint.

Clear navigation.

Three meaningful projects instead of twelve cloned tutorials.

Developers ask me every week:

What should I put on my portfolio in 2026?

This guide is the exact framework I recommend.

Why a Frontend Developer Portfolio Still Matters in 2026

LinkedIn profiles are crowded.

GitHub repositories rarely explain your thinking.

Generic link-in-bio pages look identical.

A portfolio remains the one place where you control:

Your story
Your design
Your technical decisions
Your personal brand

Companies don't just hire code.

They hire problem-solvers.

Your portfolio is where you demonstrate that.

What Visitors Notice First

Most visitors decide within seconds whether to continue exploring.

They're looking for signals:

Signal	What Good Looks Like
Role clarity	Frontend Engineer • React • Next.js
Live proof	Working project links
Performance	Fast loading pages
Honesty	Clear ownership of work
Contact	Easy-to-find email or LinkedIn
Communication	Blog posts or case studies

The best portfolios answer two questions immediately:

What do you build?
How do you think?

Common Portfolio Mistakes

1. The Template Trap

Using a template is fine.

Publishing it without customization isn't.

Hiring managers see the same templates repeatedly.

Add your own voice, structure, and design decisions.

2. Too Many Tutorial Projects

Five Netflix clones won't impress anyone.

One production-style project with:

Authentication
API integration
Error handling
Responsive design

is far more valuable.

3. GitHub as the Entire Portfolio

Most visitors won't read your code first.

Explain:

The problem
Your solution
The outcome

Make projects understandable before visitors open GitHub.

4. Ignoring Mobile Users

Many recruiters first visit portfolios from phones.

A portfolio that looks amazing on desktop but breaks on mobile loses opportunities.

Always test:

Mobile navigation
Performance
Layout shifts
Touch interactions

5. Generic Introductions

Avoid:

Passionate developer who loves coding.

Instead write something specific:

Frontend Engineer specializing in React, Next.js, and performance-focused web applications.

Specificity wins.

Portfolio Sections Every Developer Needs

You don't need 20 pages.

These seven sections are enough:

Home

Name
Role
Location
Call-to-action

Projects

3–5 strong projects
Live demos
Tech stack
Short case studies

About

Experience
Background
Personality

Skills

Group skills honestly.

Example:

Core Skills

React
Next.js
TypeScript

Familiar With

AWS
Docker
PostgreSQL

Blog

Even a few technical articles help.

Benefits:

SEO traffic
Personal branding
Communication proof

Contact

Make it simple.

Don't hide contact information behind multiple clicks.

Privacy Policy

Especially important if your contact form stores user data.

Best Frontend Portfolio Project Ideas

The strongest projects solve real problems.

Analytics Dashboard

Shows:

Charts
Data visualization
Complex UI

Multi-Step Form

Demonstrates:

Validation
State management
User experience

Documentation Platform

Shows:

Search functionality
Content architecture
Navigation design

E-Commerce Application

Demonstrates:

Product listings
Cart management
API integrations

Component Library

Excellent for frontend-focused roles.

Shows:

Reusability
Design systems
Scalability

How to Write Better Project Case Studies

Don't stop at screenshots.

Explain:

Problem

What needed to be solved?

Your Role

What exactly did you build?

Stack

Which technologies did you use?

Key Decision

What tradeoff did you make?

Outcome

What improved?

Examples:

Faster load times
Better UX
Higher Lighthouse scores

Next.js Portfolio Best Practices

If you're building a modern portfolio, Next.js remains an excellent choice.

Recommended patterns:

Use Server Components

Keep client-side JavaScript minimal.

Optimize Images

Use next/image.

Add Metadata

Every page should have:

Title
Description
Canonical URL

Add Structured Data

Useful schemas:

Person
Website
BlogPosting

SEO Tips for Developer Portfolios

Many developers ignore SEO entirely.

That creates opportunity.

Target Specific Keywords

Examples:

frontend developer portfolio
react developer portfolio
next.js developer portfolio

Create Supporting Articles

Write content around:

React
JavaScript
Performance
Career growth

Content creates long-term traffic.

Internal Linking

Link:

Blog → Projects
Projects → Contact
About → Projects

This improves discoverability.

Performance Optimization Checklist

Users notice speed.

Recommended targets:

Metric	Target
LCP	Under 2.5s
CLS	Under 0.1
INP	Under 200ms
Total JS	Keep minimal

Quick wins:

Self-host fonts
Optimize images
Lazy-load heavy components
Avoid unnecessary animations

Personal Branding That Compounds

Your portfolio should not exist in isolation.

A strong ecosystem looks like:

Portfolio website
GitHub
LinkedIn
DEV Community
YouTube (optional)

Each platform drives traffic to the others.

Over time, this creates a compounding effect.

Final Portfolio Checklist

Before publishing:

[ ] Clear role and value proposition
[ ] Mobile-friendly design
[ ] Fast page speed
[ ] Live project links
[ ] Working contact form
[ ] SEO metadata
[ ] Open Graph images
[ ] At least one technical article
[ ] Updated GitHub profile
[ ] Custom domain configured

Final Thoughts

A frontend developer portfolio isn't decoration.

It's proof.

Proof of your skills.

Proof of your decisions.

Proof of how you solve problems.

In 2026, templates and generic portfolios are everywhere.

What still stands out is:

Fast performance
Real projects
Honest case studies
Strong communication

Build something you'd be proud to share.

And keep improving it as you grow.

☕ Enjoyed This Article?

If this guide helped you and you'd like to support more content like this:

👉 Buy me a coffee: https://buymeacoffee.com/safdarali

👉 Subscribe to my YouTube channel: https://www.youtube.com/@safdarali_?sub_confirmation=1

I regularly share content about:

React
Next.js
JavaScript
AI-assisted development
Developer career growth

Your support helps me continue publishing free tutorials and in-depth articles.

Thank you for reading! 🚀

DEV Community: Safdar Ali

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

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

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

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

Migrating styles — before and after

The hybrid I use on client sites

My production setup

The single takeaway

Related reading

Zustand vs Redux Toolkit — Which State Manager in 2026?

Free Video Thumbnail Generator Online — No Upload

React 19 Features — What Actually Changed and What I Use

What actually changed at a high level

React 19 hooks and APIs — quick reference table

useOptimistic — instant feedback without lying to the user forever

use() — promises and context without useEffect hacks

Actions and forms — less boilerplate than manual fetch

What I immediately adopted

What I'm waiting on

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