Stop Treating 'use client' Like a Code Smell in Next.js

#webdev #javascript #react #nextjs

The "Server-Everything" Trap

In the current landscape of modern web development, the introduction of React Server Components (RSC) within the Next.js ecosystem has been nothing short of revolutionary. We have moved away from the "everything is a client component" era of the early 2020s toward a model that prioritizes initial load times, SEO, and reduced JavaScript bundles.

However, a dangerous trend has emerged: developers are treating use client as if it were a code smell. There is a prevailing, often unspoken pressure to keep components on the server at all costs, under the assumption that any client-side code is inherently "bad" for performance. I’m here to tell you that this is an overcorrection that is actively making your applications feel sluggish.

The Cost of Architectural Purity

Server Components are incredible for what they do: they eliminate database-to-client waterfalls and reduce the amount of JavaScript sent to the browser. But they were never intended to handle every single interaction.

When you force a modal toggle, a complex dropdown, or a real-time search input to perform a network roundtrip to the server for every keystroke or click, you are trading a snappy, responsive user experience for a misguided sense of architectural purity. The user doesn't care about your server-side rendering strategy; they care about how fast the button responds when they click it.

The Three-Question Audit

To avoid "client creep"—where unnecessary logic bloats your server components or, conversely, where server-side roundtrips bloat your latency—I use a simple heuristic. Before deciding whether to add the 'use client' directive, I run the component through this Three-Question Audit:

Does it use React hooks? (e.g., useState, useEffect, useContext)
Does it require event handlers? (e.g., onClick, onChange, onScroll)
Does it call browser-only APIs? (e.g., window, localStorage, navigator)

If the answer to all three is "no," it stays as a Server Component. If the answer to any of them is "yes," it becomes a Client Component. It is that simple.

Pattern 1: The "Leaf" Pattern

The biggest mistake developers make is placing the 'use client' directive at the top of a large file, effectively turning the entire sub-tree into client-side code. Instead, we should be using the Leaf Pattern.

Push the 'use client' directive as deep down the component tree as possible. For example, if you have a complex Navbar, don't make the entire component client-side just because of a mobile toggle menu. Extract the mobile menu into its own small, isolated component. By treating client components as isolated, interactive "islands," you can reduce your First Load JavaScript bundle by 40% to 60%.

Pattern 2: The "Children" Composition Pattern

What if you have a heavy server-side component that needs to be wrapped in an interactive client component? The solution is component composition. By passing Server Components as children to a Client Component, the interactive wrapper mounts on the client, but the heavy data-fetching subtree remains on the server.

// components/InteractiveWrapper.tsx
'use client';

import { useState } from 'react';

export default function InteractiveWrapper({ children }) {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle Content</button>
      {isOpen && <div>{children}</div>}
    </div>
  );
}

// app/page.tsx
import InteractiveWrapper from '@/components/InteractiveWrapper';
import HeavyServerContent from '@/components/HeavyServerContent';

export default function Page() {
  return (
    <InteractiveWrapper>
      <HeavyServerContent />
    </InteractiveWrapper>
  );
}

Conclusion: Performance is About Balance

In a recent production migration, adopting these two patterns helped us slash our JavaScript bundles by 57% and improve Time to Interactive (TTI) by up to 75%. We didn't do this by abandoning Server Components; we did it by being intentional about where we used them.

Stop treating use client as a failure. It is a vital tool in your belt for creating fluid, high-performance UI. Use the server for data fetching and static rendering, and use the client to bring your application to life. Your users will thank you for the extra milliseconds of speed.

DEV Community