Skip to content
Blog

Server Components: A Paradigm Shift

For years, React ran exclusively in the browser. The server sent basic HTML, then JavaScript downloaded, executed, and React took over. All rendering happened on the client.

Development3 min read
AlejandroChief Technology Officer

Server Components: A Paradigm Shift

The Previous Model

For years, React ran exclusively in the browser. The server sent basic HTML, then JavaScript downloaded, executed, and React took over. All rendering happened on the client.

This model has advantages: immediate interactivity once loaded, easy local state management, and clear separation between server and client.

It also has costs: substantial JavaScript to download, expensive hydration, data waterfalls, and added complexity for tasks the server handles naturally.

What Server Components Change

Server Components allow React components to execute on the server and send rendered HTML to the client. No additional JavaScript for those components, and no hydration required.

This differs from traditional server-side rendering, where everything renders on the server and then hydrates on the client. Instead, it creates a hybrid architecture in which each component can be designated as server or client based on its specific needs.

The Practical Implications

A component displaying data from a database can access it directly, without an intermediate API or client-side fetch. The data travels as HTML rather than JSON that must later be rendered.

Components requiring interactivity remain client components, preserving the familiar mental model. The key difference is that you can now decide on a component-by-component basis.

The JavaScript bundle shrinks dramatically because it only includes components that truly need to run in the browser.

The Conceptual Cost

You now work with two types of components that follow different rules. Server Components cannot use state hooks, event handlers, or browser APIs.

This distinction requires rethinking application structure: where to place each component, how to pass data between server and client, and what each component can and cannot do.

When It Makes Sense

Applications with substantial static or semi-static content gain the most. They benefit from reduced JavaScript, faster load times, and improved default SEO.

Interactive dashboards, where nearly everything is dynamic and reactive, see smaller gains, though layout and navigation sections still improve.

For small, simple applications, the conceptual overhead may not justify adoption.

The Future Is Already Here

Server Components represent more than an incremental improvement. They introduce a fundamentally different approach to web rendering, complete with its own advantages and complexities.

New projects in the React and Next.js ecosystem benefit from learning this model. Existing projects require careful evaluation of migration effort versus potential gains.

The future of React development incorporates this duality. Understanding it now is worthwhile.

Keep reading

Related articles

Development

The Code Slowing Down Your Website Isn't the One You Wrote

Third-party scripts are, on most of the websites we audit, the biggest source of slowness. Not the framework, not the images, not the server: the code you load from other domains. Analytics, support chat, advertising ...

Development

The Language That Machines Actually Understand

Structured data is the most direct way to explain to a machine what your page contains. A human reads “Different Growth, web development agency, rated 4.9 out of 5” and understands it instantly. A search engine, howev...

Next step

Do you have a project in mind?

If this article was useful and you want to know how we can help, we are here to listen.