A story on Frontend Architectures - Back to the Future

Source: Dev.to

Introduction

So far we’ve explored how web architectures have evolved—from static, magazine‑style pages to animation‑heavy sites built with various strategies for shipping faster, better, and more reliable experiences.

Much of that evolution focused on efficiently using the backend to serve the frontend. Consequently, developers began loading massive amounts of JavaScript into sites, especially with Single‑Page Applications (SPAs).

Think of a webpage as a canvas:

• HTML – the borders.
• CSS – the colors and shapes.
• JS – the artist that adds the details.

In a SPA‑heavy world we started handing over too much of this painting work to JavaScript.

Illustration – Refer to the image below

Even if the browser receives the first byte and paints something on the screen (First Contentful Paint), that content may never be useful:

• Largest Contentful Paint (LCP) occurs, but clicks feel unresponsive because the JavaScript thread is busy (First Input Delay).
• Layouts keep shifting as scripts load (Cumulative Layout Shift).

So while the page appears to be loading, the user experience is stuck in limbo…

• Is it happening?
• Is it useful?
• Is it usable?

We need rendering strategies beyond shipping a truckload of JavaScript to the client.

In this article we’ll discuss:

1. Why the future is nudging us back toward server‑centric rendering.
2. The different strategies that make the web faster.
3. “Next‑generation” architectural patterns, their pros and cons.
4. Suitable use‑case scenarios for each approach.

1️⃣ CSR – Client‑Side Rendering

What it is

The generic rendering approach where the client does almost all of the heavy lifting: it fetches data from the server and renders the UI at runtime.

Build‑time work

Minimal, but bundling and optimisation can still be complex because an entire app bundle is produced during the build stage.

Typical symptoms

• Blank screen → loading spinners
• JavaScript parse + execution delays

This is the classic slow FCP / LCP problem.

When to use

Highly interactive apps where SEO or first‑paint performance matters less (e.g., internal dashboards, SPAs).

2️⃣ SSG – Static Site Generation

• What it is – Pre‑rendering pages at build time, then serving static HTML.
• Key metric – TTFB (Time To First Byte) is excellent.

Best for – Sites that need strong SEO and rarely change content, such as documentation, marketing pages, blogs, etc.

Drawback – If content changes frequently, the site can become stale until the next build.

3️⃣ SSR – Server‑Side Rendering

• What it is – The server renders HTML on each request and sends it to the client.
• Benefit – Fresh, dynamic content on first load.

Note: SSR only helps with the initial HTML, not with real‑time updates.

• When to use – Highly dynamic / personalized pages and real‑time dashboards that must be up‑to‑the‑second on every request.
• Cost – Higher per‑request compute and latency compared to cached static HTML.

4️⃣ ISR – Incremental Static Regeneration

Origin: Pioneered by Next.js to combine the best of SSG and SSR.

Why ISR exists

1. SSG is fast but cannot update without a full rebuild.
2. ISR serves static cached pages instantly and allows selected pages to be regenerated (on‑demand or after a revalidate period) without rebuilding the whole site.

How ISR works (simplified timeline)

Why the stale HTML is served at t = 61

• Speed > Freshness – Users prefer instant pages over perfectly fresh but slow ones.
• Only ONE request ever sees stale‑after‑expiry – The first request triggers regeneration; all later requests get fresh content (request collapsing).
• No blocking – Regeneration never delays a response.
• Most users don’t refresh immediately, so by the time they do the cache is already updated.

You can also trigger on‑demand regeneration via webhooks from your database, eliminating stale content entirely while keeping static‑fast performance.

Ideal use cases

• Mostly static but periodically updating content
• Strong SEO needs
• Large number of pages (e.g., blogs, documentation, product detail pages, category pages)

When not to use ISR

• Real‑time data (stocks, live scores)
• User‑specific dashboards
• Financially critical per‑request accuracy
• Any scenario requiring real‑time or per‑user rendering, background crawling of all pages, etc.

5️⃣ RSC – React Server Components

Let’s run the clock back a bit to see how servers and clients interacted to show sites in the browser.

In CSR, a React application sends a request from the client to the server, and the server returns a bundle of JavaScript that the client must download, parse, and execute before any UI appears. This model pushes most of the work to the client, leading to the performance problems discussed earlier.

React Server Components (RSC) flip this model:

• Components are rendered on the server without sending their JavaScript to the client.
• The server streams HTML + serialized component data to the client.
• The client only receives the minimal JavaScript needed for interactivity.

Benefits

1. Reduced JavaScript payload – Faster download and parse times.
2. Improved SEO – Content is present in the initial HTML.
3. Better developer ergonomics – You can write components that run where they make the most sense (server vs. client).

RSC is still evolving, but it represents a promising direction for balancing server‑side performance with client‑side interactivity.

Summary

How to choose

• Content freshness – If the data changes often, prefer SSR or ISR.
• SEO requirements – SSG and SSR provide pre‑rendered HTML for crawlers.
• Interactivity – CSR and RSC excel when the UI needs rich client‑side behavior.
• Infrastructure constraints – Consider compute cost (SSR) vs. build time (SSG/ISR).

Understanding these trade‑offs lets you pick the rendering strategy that delivers faster, more reliable web experiences aligned with both user expectations and business goals.

From CSR to RSC: Why Server‑Side Rendering Isn’t Enough

A minimal HTML shell that references the JS bundle forces the browser to download that bundle on the client. This causes a very late “First Paint” and hurts SEO.

The SSR Solution

Next.js introduced Server‑Side Rendering (SSR):

• The rendering shell (and its DB queries) runs on the server.
• The server returns a fully rendered HTML document (with CSS links).
• Content appears immediately, reducing the first‑paint time.

But even with SSR there is still a large JS bundle that must be downloaded, slowing the time‑to‑interactive screen.

Enter React Server Components (RSC)

Eureka moment: server components!

You might think, “Isn’t this just SSR again?” No – RSC is different.

Benefits

• Only the interactive components (e.g., 5 out of 20) are shipped, hydrated, and executed on the client.
• JS bundle size is dramatically reduced.
• RSC works with React Suspense, enabling streaming chunks of UI, progressive rendering, and server‑side streaming support.

Why a Framework Is Needed

Implementing RSC requires infrastructure for:

• Serializing component trees
• Streaming payloads to the client
• Coordinating with Suspense and hydration

That’s why Next.js 13 App Router became the first mainstream RSC implementation.

The Evolution of Front‑End Rendering

The progression shows that front‑end architecture isn’t about picking a single “best” rendering strategy. It’s about placing work where it makes the most sense:

• Push too much logic to the client → performance suffers.
• Bring work back to the server → the web becomes faster and more usable.

Modern frameworks now let us mix these strategies thoughtfully, balancing speed, freshness, interactivity, and scale—rather than overloading the browser with work it was never meant to do.

The future of the web isn’t client‑first or server‑first; it’s responsibility‑first.