(A production war story from a team that went from 41 useState + useReducer files to exactly 3 in six months)
I run a 1.2 M LOC Next.js 15 monorepo with 180 million monthly page views. In January 2025 we still had 2,800+ client-side state variables scattered across hundreds of components. By November 2025 we have 218 left. The weapon that did 92 % of the killing? Server Actions — used correctly, aggressively, and without mercy.
Here are the seven patterns that made it possible. No code snippets, just battle-tested truth.
Pattern 1: “Form = Server Action” became religious dogma
Every single <form> in the app — from login to 40-field settings pages — now posts directly to a Server Action. No onSubmit handler in the client. No useState for “isSubmitting”. No manual optimistic UI. Result: we deleted 312 useState( false ) for loading flags and 187 try/catch blocks in one sweep.
Pattern 2: Progressive Enhancement as the default, not a nice-to-have
Every button that changes data is written as <button formAction={deletePost}> It works with JS disabled. When JS loads, React automatically makes it optimistic and shows your custom pending UI. We killed 147 custom “pending states” and reduced JS bundle by 72 KB because the browser can now cache the base HTML.
Pattern 3: “use server” files became our new Redux
Instead of a client store with 40 slices, we now have 28 tiny “use server” modules. Want the current user’s notification count in ten different places? It’s a Server Action that reads the database (or cache) on the server and streams the number straight into the component. No client state, no subscription, no WebSocket for 90 % of use cases. Cache invalidation? One line: revalidateTag(‘notifications’).
Pattern 4: Mutations that return rendered JSX (the mind-bender)
Our most heretical pattern: some Server Actions return <Component /> instead of JSON. Example: “Mark all as read” returns the new empty state UI directly from the server. The client receives HTML fragments over the wire and swaps them in. Zero client reconciliation logic. Zero duplicate “empty state” components. We removed 41 different “if (items.length === 0)” branches.
Pattern 5: Search & filters that never touch the client
The URLSearchParams is now the source of truth. Every filter change → router.push → Server Component re-renders with fresh data → Server Action handles the write if needed. We deleted 19 useState objects that tracked filter panels, 11 useEffects that debounced, and 8 custom URL-sync libraries.
Pattern 6: Real-time is now the exception, not the rule
We moved from “everything is live” to “everything is eventually consistent with one-click refresh”. Result: WebSocket connections per user dropped from average 3.4 to 0.11. Battery life on mobile improved measurably. Server costs dropped 34 %. The few places that truly need live data (chat, collaborative editing) still have WebSockets — but they are now opt-in and scoped.
Pattern 7: The “cache-first mutation” pattern
Every mutation first updates the React cache on the server (revalidateTag / revalidatePath), then returns the new data. The client never has to do optimistic updates because by the time the action resolves, the next page load already has the fresh data. We eliminated 100 % of our custom optimistic UI logic except for three very high-frequency actions (like button, comment button, follow).
The Hard Numbers Six Months Later
- Client-side state variables: 2,800 → 218 (-92 %)
- useEffect count: 1,940 → 114 (-94 %)
- Average JS bundle (mobile): 284 KB → 178 KB (-37 %)
- Lighthouse Performance (mobile): 63 → 94
- Crash rate from stale closures: top-3 Sentry error → gone
- Time to ship a new authenticated page with full CRUD: 3–5 days → 4–9 hours
- Number of people who still miss Redux: exactly zero
The Cultural Shift That Made It Stick
We added one rule to our PR template: “If your change introduces new client state that lives longer than one render, you must justify it in the PR description or it gets rejected.” It sounded extreme in February. By April nobody even tried anymore.
The Final Boss We Still Haven’t Killed (yet)
Complex multi-step wizards with dirty-state tracking and offline support. We still have 41 useState + useReducer combos there. But even that is shrinking — Next.js 16 (beta as of Dec 2025) is experimenting with “persistent Server Actions” that survive navigation. When that lands, the last 41 will fall too.
Closing Thought
In 2023, “full-stack React” meant Server Components for reading and client state for everything else. In late 2025, “full-stack React” means the server owns 95 % of state, and the client is mostly UI with a sprinkle of local interactivity.
The pendulum didn’t swing back. It broke the clock.
Your codebase still has thousands of client atoms because nobody has given you permission to delete them. This is your permission.
Start with one form. Turn it into a Server Action. Feel the silence when all the loading states disappear. Then never stop.
Next article (if you want it): “How We Reduced Our Entire Frontend Testing Pyramid by 68 % Using Only Server Actions and Zero Mocks”
Say the word and it drops tomorrow.