DEV Community: Farhad Faraji

CSR vs SSG vs SSR: What They Mean and How React & Next.js Use Them

Farhad Faraji — Wed, 10 Sep 2025 12:38:56 +0000

Hey there! If you're new to web development, you might have heard buzzwords like CSR, SSG, and SSR thrown around. They sound technical, but don’t worry, I’m going to break them down as if we’re having a chat with the browser, HTML, and JavaScript. Think of it like a friendly conversation where each part of the web explains its role. Let’s dive in and make sense of why people say “Next.js is great for SEO” with simple examples using React and Next.js.

The Beginning: Plain HTML (The Browser’s Story)

Browser: Hey, I’m the browser, Chrome, Firefox, or whatever you’re using. When someone visits a webpage, they send me an HTTP request, and I grab an HTML file from a server. My job is simple:

I parse the HTML to build the structure of the page.
If there’s CSS, I use it to make things pretty.
If there’s JavaScript, I run it to add interactivity.

HTML: I’m the backbone! For a basic webpage, I’m just a static file with some tags. Like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Basic Page</title>
  </head>
  <body>
    <h1>Welcome to my page!</h1>
    <p>I’m just static content, ready to go.</p>
  </body>
</html>

Browser: When I get this HTML, I display it instantly. No fuss, no waiting. Search engines like Google love me because I’m straightforward, and they can read my content right away. But if you want a fancier, interactive page, I need some help from JavaScript.

Enter React: Client-Side Rendering (CSR) (JavaScript Takes the Stage)

JavaScript: Hey, I’m JavaScript, and I make things dynamic! With React, I can build complex, interactive UIs that update without reloading the whole page. But here’s how it works in a Client-Side Rendering (CSR) setup:

HTML: In a React app, I’m super minimal at first. I might look like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>React CSR Example</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="main.js"></script>
  </body>
</html>

Browser: When I get this HTML, it’s basically empty, just a <div id="root">. I’m like, “Uh, where’s the content?” I have to wait for JavaScript to load and run.

JavaScript: That’s where I come in! I use React to fill that empty root div with awesome content. Check this out:

// main.js
import React from "react";
import ReactDOM from "react-dom/client";

function App() {
  return <h1>Hello from React CSR!</h1>;
}

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<App />);

Browser: Once JavaScript runs, I finally see the <h1>Hello from React CSR!</h1> and display it. It’s cool, but there’s a catch…

Search Engine Crawler: Hey, I’m Google’s crawler. I visit pages to index them for search results. When I see that empty <div id="root">, I might not wait for JavaScript to load. So, I could miss the content, which is bad for SEO.

JavaScript: Yeah, that’s the downside of CSR. I’m great for interactive apps, but search engines might not see the full page right away because I do all the rendering in the browser.

Next.js and Pre-Rendering (The Server Steps In)

Server: Hey, I’m the server, and Next.js is my buddy. Unlike plain React, I can pre-render HTML before sending it to the browser. That means the browser and search engines get a fully loaded page from the start.

Browser: Oh, nice! So when I get a page from Next.js, it’s already filled with content? No waiting for JavaScript?

Server: Exactly! With Next.js’s App Router, I render the JSX on the server and send a complete HTML document. Search engines love this because they see the content immediately.

Search Engine Crawler: Yup, I can index that pre-rendered HTML right away. That’s why people say Next.js is SEO-friendly; it’s like serving me a ready-to-read page.

Static Site Generation (SSG) (The Pre-Baked Cake)

Server: Let’s say you have a page with content that doesn’t change often, like a blog homepage or a marketing page. With Static Site Generation (SSG), I generate the HTML at build time, like baking a cake before the party starts.

Browser: So, when I request the page, you just hand me that pre-baked HTML?

Server: Yup, it’s super fast because the work’s already done. Here’s an example in Next.js:

// app/page.js
export default function Home() {
  return <h1>Hello from Next.js SSG!</h1>;
}

Server: I build this HTML once during the build process, and then I serve it to every user who visits. It’s lightning-fast and great for static content.

Search Engine Crawler: Love it! I get the full HTML right away, so indexing is a breeze.

JavaScript: Do I even need to do anything here?

Server: Not much! The browser can still run JavaScript for interactivity, but the heavy lifting is done by me at build time.

Server-Side Rendering (SSR) (Fresh Content Every Time)

Server: Now, what if your data changes often? Like a list of celebrities that updates every hour? That’s where Server-Side Rendering (SSR) comes in. I fetch the latest data for every request, generate fresh HTML, and send it to the browser.

Browser: So, I get a new, fully rendered page every time?

Server: Exactly. Here’s how it looks in Next.js:

// app/celebrities/page.js
async function getCelebrities() {
  const res = await fetch("https://api.example.com/celebrities", {
    cache: "no-store", // ensures fresh data on every request
  });
  return res.json();
}

export default async function CelebritiesPage() {
  const celebrities = await getCelebrities();

  return (
    <div>
      <h1>Celebrity List</h1>
      <ul>
        {celebrities.map((c) => (
          <li key={c.id}>{c.name}</li>
        ))}
      </ul>
    </div>
  );
}

Server: For every request, I call getCelebrities(), build the HTML with the latest data, and send it to the browser. It’s fresh every time.

Search Engine Crawler: Perfect! I always see the latest content, so I can index it accurately.

Browser: And I display it instantly without waiting for JavaScript to fill in the blanks.

JavaScript: I can still add interactivity after the page loads, right?

Server: Yup, you can take over for things like button clicks or dynamic updates, but I handle the initial render.

Quick Recap (Everyone Chimes In)

Browser: So, let’s sum it up:

CSR (React default): I get an empty HTML with a <div id="root">. JavaScript does all the work in the browser, but it’s not great for SEO because crawlers might miss the content.
SSG (Next.js): I get pre-baked HTML from the server at build time. It’s super fast and great for static stuff like blogs.
SSR (Next.js): I get fresh HTML from the server for every request, perfect for dynamic content like live data.

Search Engine Crawler: Next.js is my favorite because it gives me pre-rendered HTML, whether it’s SSG or SSR. I can index it easily, which makes Next.js awesome for SEO.

JavaScript: And I still get to shine in Next.js for interactivity, even if the server does the heavy lifting for rendering.

🚀 You: Now that you’ve heard from the browser, HTML, JavaScript, and the server, you should have a clear picture of when to use CSR, SSG, or SSR, and why Next.js is a powerhouse for building modern, SEO-friendly websites.

Do We Really Need Redux for Profile Data? Managing User State with TanStack Query

Farhad Faraji — Tue, 19 Aug 2025 09:50:40 +0000

For years, the go-to solution for managing global state in React apps was Redux (and later, lighter options like Zustand). But in many cases, especially when the state comes directly from the server, you don’t need a state management library at all.

This post will walk through a common scenario: keeping a user profile available across the frontend. We’ll see how TanStack Query makes this effortless (with caching, invalidation, and persistence) without Redux or Zustand.

🧩 The Problem

Imagine you have an endpoint /api/me that returns the authenticated user’s profile. You want this profile data:

Available across your app (navbar, settings page, etc.)
Persisted in memory, without refetching on every render
Revalidated only when necessary (e.g., after updating profile)
Cleared out on logout

Traditionally, we’d reach for Redux or Zustand to:

Fetch profile once
Store it in global state
Manually update/remove when needed

But TanStack Query does this out of the box.

⚡ Setting Up TanStack Query

First, install the dependencies:

npm install @tanstack/react-query axios

Wrap your app with the QueryClientProvider:

import { QueryClient, QueryClientProvider } from '@tanstack/react-query';

const queryClient = new QueryClient();

export function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <YourRoutes />
    </QueryClientProvider>
  );
}

📦 Defining the Profile Query

Instead of scattering query config across your codebase, it’s best to define a query object and re-use it everywhere:

// profileQuery.ts
import { queryOptions } from '@tanstack/react-query';
import axios from 'axios';

async function fetchProfile() {
  const { data } = await axios.get('/api/me');
  return data;
}

export const profileQuery = queryOptions({
  queryKey: ['profile'],
  queryFn: fetchProfile,
  staleTime: Infinity, // profile doesn’t change often
  gcTime: Infinity,    // keep it cached until explicitly cleared
});

🎯 Using the Profile Across Components

Now you can import and use this query anywhere:

import { useQuery } from '@tanstack/react-query';
import { profileQuery } from './profileQuery';

function Navbar() {
  const { data: profile } = useQuery(profileQuery);
  return <span>Welcome, {profile?.name}</span>;
}

function SettingsPage() {
  const { data: profile } = useQuery(profileQuery);
  return <div>Email: {profile?.email}</div>;
}

✅ Both components read from the same cached query.

✅ No prop drilling.

✅ No Redux/Zustand boilerplate.

🔄 Revalidating Profile After Update

When you update the profile, just invalidate the query so it refetches:

import { useMutation, useQueryClient } from '@tanstack/react-query';
import axios from 'axios';

function useUpdateProfile() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (updates) => axios.put('/api/me', updates),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['profile'] });
    },
  });
}

This ensures your UI always has the latest profile, without manual state juggling.

🚪 Handling Logout

On logout, just remove the cached profile query:

function useLogout() {
  const queryClient = useQueryClient();

  return () => {
    // Call your logout API
    queryClient.removeQueries({ queryKey: ['profile'] });
  };
}

This clears the user data instantly from memory.

📌 Takeaways

TanStack Query can act as your global store for server state.
Use infinite cache time for stable data like profiles, and manually invalidate on updates.
Store query configuration (key, fn, cache time) in a query object to re-use cleanly across your app.
For logout, simply remove the query.

👉 The result? No reducers, no actions, no global store overhead, just queries.

💡 Pro tip: Use Zustand (or React context) only for client, only UI state (e.g., theme, modal toggles). For server data, TanStack Query has you covered.