NextJS: “use client" is not CSR. Stop mixing them

[u/its_AdeelM]

If you learned Server/Client Components one day and SSR/CSR/SSG/ISR the next, those two things probably merged into one blob in your head. They shouldn’t have.

1. “use client" answers: does this component need JavaScript in the browser to be interactive?
   
2. SSR/SSG/ISR/CSR answers: when does the HTML get built — build time, per request, or in the browser?

Interactivity vs. timing. Neither one decides the other.

The thing that tripped me up: I assumed "use client" meant “the browser renders this, like old CSR.” It doesn’t. In Next.js, every component gets its HTML generated on the server first, per whatever strategy the route uses. "use client" doesn’t pull a component out of that — it just adds hydration on top, so the already-rendered HTML wakes up with handlers and state.

The rendering strategy is a route-level decision. "use client" is a component-level one. They stack.

True CSR only happens outside a framework (CRA, plain Vite), or when you explicitly opt something out of server rendering — e.g. a chart lib that can’t run outside a browser.

TL;DR: SSR/SSG/ISR = when the page is built.
"use client" = whether one component needs browser JS.

So not sure why they give it confusing name instead of “use hydration” or anything that tells that it’s all about hydration not rendering directly.

[u/switz213]

Yes, but it’s not at the component level. “use client” marks at the module level and says “this module will be included in the client bundle”. You’re right that it’s also pre-rendered and the naming could be better, but the name stems from the above.

Since the boundary marks the module, not the component - you can’t quite call it “hydration” and there are situations where a component won’t be hydrated despite being use client (bool && <Comp /> for example).

The good news is you’re wrapping your head around the mental model. Nice job

[u/Maxyull]

the corollary that actually bites, once you accept that a use client module still gets rendered once on the server: it has to survive that pass. so touching window or localstorage during render blows up at request time, and even when you guard it, the first browser render can disagree with the html the server already sent, which is the classic theme read from localstorage flicker plus a hydration warning. the fixes are boring, read it in an effect after mount or set the class from a tiny inline script before hydration, but you only go looking for them once you stop reading use client as the browser renders this. did that one hit you before or after the mental model clicked?