The "use client" Tax

Why React Server Components force small interactive ideas into file-sized boundaries — and why that boundary should be lexical instead.

There is a moment that every developer who tries React Server Components hits, usually within their first hour. They write a server component. It fetches some data. It renders a list. Beautiful. Then they want a button that toggles a filter, and the compiler stops them: "you can't use useState here." So they cut the interactive piece out, paste it into a new file, sprinkle "use client" at the top, import it back into the parent, and move on.

A week later their components/ directory looks like this:

components/
├── product-list.tsx
├── product-list-filter.tsx
├── product-list-filter-input.tsx
├── product-list-sort.tsx
├── product-list-sort-dropdown.tsx
├── product-card.tsx
├── product-card-actions.tsx
├── product-card-favorite-button.tsx
└── product-card-quantity-stepper.tsx

Nine files for one product list. Each one a thin wrapper. Each one with two or three lines of real logic. Each one named with an increasingly desperate suffix because the original Filter already exists three directories up.

This is the "use client" tax, and it is real.

Where the tax comes from

The directive is not arbitrary. "use client" marks a module boundary that the bundler uses to split graphs: everything reachable from a "use client" entry becomes part of the client bundle; everything else stays on the server. The directive has to live at the top of a file because that is the granularity the bundler operates on. Modules in, modules out.

That works fine in theory. In practice it forces a one-to-one correspondence between interactive concerns and files on disk, and interactive concerns are not file-sized. They are paragraph-sized. A "favorite" button that toggles state is not a module — it is two lines inside the card that displays the product. But the runtime can't see those two lines unless you lift them into their own module, give them a name, export them, import them back, and pass props across the boundary.

The result is a particular kind of friction that compounds:

File sprawl. Trivial widgets become trivial files. Most of the file is the import header.

Naming fatigue. Every extracted leaf needs a name. Names that were unique in their lexical scope are no longer unique once they live in a flat directory. You end up with ProductCardFavoriteButtonInner.

Lost colocation. A server function that writes to the database and the form that calls it now live in two files. The relationship between them survives only as an import statement. To understand the feature you alt-tab.

Indirection without abstraction. Each extracted client component is a wrapper that accepts everything the parent had in scope, as props. You are manually performing closure conversion — by hand, every time, with no help from the compiler.

Compositions you can't write. The pattern that hurts most is the one you cannot express at all: a server function that computes some data and returns a small interactive component bound to that data. You cannot do this in standard RSC, because the client component has to be a separate module, which means it cannot close over server-side values. You always end up exporting the client component, exporting the data fetch, and re-assembling them at the call site. The expression you wanted to write — a factory — is not available to you.

The shape of the pain

Here is what a real fragment looks like under the current rules:

// product-card.tsx
import { FavoriteButton } from "./product-card-favorite-button";

export async function ProductCard({ id }) {
  const product = await db.product.find(id);
  return (
    <article>
      <h3>{product.name}</h3>
      <FavoriteButton productId={product.id} initial={product.isFavorite} />
    </article>
  );
}

// product-card-favorite-button.tsx
"use client";

import { useState } from "react";
import { toggleFavorite } from "./product-actions";

export function FavoriteButton({ productId, initial }) {
  const [favorite, setFavorite] = useState(initial);
  return (
    <button
      onClick={async () => {
        setFavorite(!favorite);
        await toggleFavorite(productId);
      }}
    >
      {favorite ? "★" : "☆"}
    </button>
  );
}

// product-actions.ts
"use server";

export async function toggleFavorite(productId: number) {
  // ...
}

Three files for a star button. Two of them exist purely as plumbing for the directive system. The actual interesting code — eight lines of state and a database write — is buried under thirty lines of imports, exports, and prop-passing.

This is what people mean when they say RSC is heavy. It is not the data fetching. It is not the streaming. It is this: the directive system asks you to manually re-architect every interactive idea into a multi-file module graph, and it does so for the smallest possible units of behavior.

Zoom out one level and the same pressure exists at the project boundary: modern frontend frameworks force entire micro-apps to be scaffolded across directory trees, config files, and node_modules for the same kind of mechanical reason — tooling that operates at a coarser unit than the developer's idea. I covered that version of the problem in The Forgotten Joy of node app.js. The fix is structurally the same as the one proposed below: stop letting the file system be the unit of expression.

The constraint is in the tool, not in the model

Here is the part that is worth saying out loud: the file-level restriction is a property of how bundlers were built, not a property of what the directive means. "use client" is asserting that a piece of code runs on the client and must be serialized across a runtime boundary. That assertion is perfectly meaningful at any function scope. It only has to live at the top of a file because that is what the bundler can see.

A compiler that knows about RSC directives can do better. Given a server module that contains a nested function marked "use client", it can:

1. Identify the nested function and the variables it captures from its lexical scope.
2. Lift the function into a synthetic module that the bundler treats exactly like a regular "use client" module.
3. Replace the original definition with a reference to the lifted module.
4. Inject the captured variables as props at the call site.

The developer wrote one file. The bundler sees the module graph it needs. Nothing about the underlying RSC contract changes — the same serialization rules apply, the same boundary is enforced — but the file system stops being the unit of expression. The function does.

What this should look like

Imagine writing the favorite button like this instead:

export async function ProductCard({ id }) {
  const product = await db.product.find(id);

  function FavoriteButton() {
    "use client";
    const [favorite, setFavorite] = useState(product.isFavorite);

    async function toggle() {
      "use server";
      await db.product.toggleFavorite(product.id);
    }

    return (
      <button onClick={async () => { setFavorite(!favorite); await toggle(); }}>
        {favorite ? "★" : "☆"}
      </button>
    );
  }

  return (
    <article>
      <h3>{product.name}</h3>
      <FavoriteButton />
    </article>
  );
}

One file. Server fetch, client interaction, server function — colocated, in the order you would read them, sharing a closure. The compiler does the lifting; the captured product becomes a prop on the synthesized client module; the inner "use server" function becomes a bound server function with the right scope. Server → client → server nesting works recursively because the same extraction pass runs until no nested directives remain.

This is what a real RSC ergonomic story looks like. Not a new mental model — the same one — just expressed at the granularity humans actually think in.

Why this should be a standard feature

The technique is not exotic. It is closure conversion, a transform compilers have been doing since the seventies. The hard part is wiring it into the RSC plugin chain so that virtual modules generated for inline directives flow through the same client/server graph the rest of the system already uses. That is engineering, not research.

There is no fundamental reason an RSC-capable runtime cannot support this. The directive system is already a contract between the developer and the compiler; expanding it to cover function scopes in addition to module scopes does not change serialization, bundling, streaming, or the security boundary. It only changes where the developer is allowed to write the directive.

If you are building an RSC runtime: pick this up. If you are using one that does not have it: ask for it. A "use client" file is not a feature. It is a workaround for a constraint we no longer need to accept.

The point of RSC was to let us put server logic and client logic next to each other. The directive system, taken at face value, does the opposite: it forces them apart, file by file, until your repository is ninety percent wrappers. We can fix this. It is time to make the fix standard.