Server Components vs Client Components: The Mental Model Shift Every Vite Developer Needs

Introduction

If you have been building applications using Vite, you are likely accustomed to the Single Page Application (SPA) paradigm. In this world, every component you write is essentially a "Client Component." The entire JavaScript bundle is shipped to the browser, the DOM is hydrated, and all logic executes on the user's machine.

However, the React ecosystem is undergoing a massive shift toward React Server Components (RSC). For developers moving from a Vite-based setup to Next.js, this isn't just a syntax change—it's a fundamental shift in how we think about data fetching, interactivity, and the lifecycle of a component.

In this article, we will break down the mental model shift required to master the transition from Vite to Next.js App Router.

The Vite Baseline: Everything is Client-Side

In a standard Vite + React project, your component tree looks like this:

// App.tsx
import { useState, useEffect } from 'react';

function App() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/data').then(res => res.json()).then(setData);
  }, []);

  return <div>{data ? <Display data={data} /> : <Loading />}</div>;
}

Here, the browser downloads the JS, executes the useEffect, fetches the data, and updates the state. This is simple, but it leads to "waterfalls" where the user stares at a loading spinner while the browser does all the heavy lifting.

The Next.js Shift: Server by Default

In the Next.js App Router, every component is a Server Component by default. They do not ship any JavaScript to the client. They execute only on the server, render to HTML, and are sent to the browser.

1. Data Fetching as a First-Class Citizen

In Vite, we use useEffect or libraries like TanStack Query. In Next.js Server Components, we simply use async/await directly in the component body:

// page.tsx (Server Component)
async function Page() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return <main>{/* Render data directly */}</main>;
}

This eliminates the need for useState and useEffect for initial data fetching. The mental shift here is: The server is your new data layer.

2. The Interactivity Boundary

You cannot use hooks like useState, useContext, or useEffect in a Server Component. If you need interactivity (buttons, forms, real-time updates), you must explicitly mark a file as a Client Component using the "use client" directive at the top.

"use client";

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

The "Leaf Component" Strategy

A common mistake for Vite developers migrating to Next.js is putting "use client" at the very top of the layout or page. This effectively turns your Next.js app back into a Vite-style SPA, losing all the performance benefits of Server Components.

Instead, you should aim to keep the majority of your application in Server Components and push interactivity to the "leaves" of your component tree. For instance, a blog post should be a Server Component, but the "Like" button should be a Client Component.

If you find the architectural transition daunting, tools like ViteToNext.AI can help automate the migration of your Vite + React projects to Next.js, handling the initial heavy lifting of refactoring your project structure.

Comparing the Lifecycles

Feature	Vite (SPA)	Next.js (RSC)
Rendering	Client-side	Server-side (static/dynamic)
Data Fetching	Client-side (hooks)	Server-side (async/await)
Bundle Size	Larger (entire app)	Smaller (server logic is excluded)
Security	API keys exposed to client	Secrets stay on server

When to Use Which?

• Use Server Components for: Data fetching, accessing backend resources (databases/file systems), and large dependencies that don't need to be on the client.
• Use Client Components for: State, Effects, Browser APIs (window/localStorage), and Event Listeners (onClick, onChange).

Conclusion

Moving from Vite to Next.js requires unlearning the habit of putting everything in useEffect. By embracing Server Components, you significantly reduce the amount of JavaScript sent to the client, leading to faster First Contentful Paint (FCP) and better SEO.

The mental model shift is simple: Start on the server, and only move to the client when you need to handle user interaction.

Further reading: Learn more about automating your migration to Next.js