In the mid-2010s, web developers started treating server-rendered HTML as something old-fashioned.
React, Vue, and Angular ushered in the SPA era. "The server just serves the API" became the dominant philosophy. Fast interactions, app-like experiences, clean separation between frontend and backend. Everyone ran in that direction.
And now, in 2026, we are quietly but unmistakably going back to the server.
What SPAs Promised vs. What Actually Happened
The promise of SPAs was clear: load once, navigate without full page refreshes, reduce server load, dramatically improve UX.
Reality played out a little differently.
- First load got slower. The browser receives an empty HTML shell, downloads hundreds of kilobytes of JavaScript, parses it, executes it — and only then does anything appear. Users stare at a white screen.
- SEO broke. If a search engine can't execute JavaScript, it sees an empty page. Even when Google does crawl properly, indexing timing is slower and less reliable than SSR.
- Bundle sizes exploded. As features grew, JavaScript bundles ballooned. Initial JS bundles over 500KB–2MB became commonplace. Code splitting helped, but complexity kept climbing.
- Client-side state management became a nightmare. Redux, MobX, Zustand, Jotai... things that would have taken one line on the server ballooned into tens, sometimes hundreds of lines of state management code.
What Changed in 2026
Next.js App Router becoming the default
The App Router introduced in Next.js 13 has now settled in as the de facto standard for new projects in 2026. React Server Components (RSC) opened a new paradigm: render on the server by default, handle interactivity on the client only where needed.
You can choose server or client at the component level. Server components don't ship to the bundle at all. You can run database queries directly inside a component — just like PHP used to do. But with the full React ecosystem intact.
Server-first architecture in the AI era
As AI features moved into web apps, the server's role became critical again. LLM API calls, embedding generation, vector search — all of this needs to happen server-side for security alone. In a pure SPA architecture, you'd need a separate backend to handle this safely. With SSR, it's solved naturally.
Core Web Vitals with real consequences
Once Google started factoring LCP (Largest Contentful Paint), FID, and CLS into search rankings, slow SPAs started paying a real SEO penalty. SSR — which sends fully-rendered HTML — has a structural advantage on these metrics.
The rise of Astro, Remix, and SvelteKit
Frameworks built around "server-rendered by default, client-side only when necessary" have grown fast. Astro in particular set a new performance benchmark with its Islands Architecture: ship zero JavaScript by default.
The Misconception: Isn't SSR Slow?
A common pushback: "Doesn't SSR put more load on the server and slow things down?"
In 2015, that was fair. SSR then meant generating HTML on the server for every single request, with direct cost implications.
Today it's different.
- Edge Runtime: Vercel, Cloudflare Workers, and similar platforms run SSR at the edge — the compute node closest to each user. Latency is minimal.
- Streaming SSR: Instead of generating all the HTML before sending anything, the server streams it — ready parts first. TTFB (Time To First Byte) improves dramatically.
- Incremental Static Regeneration: Pages that don't change often get cached and only regenerate when needed. Static site speed plus dynamic data.
The result: TTFB drops significantly, and users see an almost-instant first screen.
SPAs Aren't Dead
To be honest, SSR isn't always the right answer.
Dashboards, admin panels, real-time collaboration tools — apps with no SEO requirements and complex interactions are still well-suited to SPAs. If users only access the app after logging in, UX responsiveness matters more than initial load time.
The trend isn't converging on "SSR vs SPA" as a binary. It's converging on hybrid. Public pages rendered server-side, authenticated dashboards running as SPAs — this architecture is becoming the standard.
What I Experienced Building With It
I built TalkWith.chat on Next.js App Router.
The public pages — today's debate topic, the archive, the rankings — are server components that query Supabase directly and send back fully-rendered HTML. No separate API routes, no client-side fetch. The code shrank by nearly half, and LCP improved noticeably.
Interactive elements — the like button, the opinion submission form — are client components declared with 'use client'. Mixing server and client where each makes sense clicked immediately. It just felt right.
The Summary
The return to server-side rendering isn't a step backward.
The SPA era gave us real experience with the limits of client-first architecture. What's coming back is a more refined form of server rendering. React Server Components, Streaming SSR, Edge Runtime — this isn't your PHP-era server rendering.
The era where developers can freely choose where each boundary between server and client lives has arrived.
And in 2026, the web is making it clear: for most cases, the default should be the server.
This is the second post in my TalkWith.chat dev log series.
First post: The Limits of Vibe Coding — What Nobody Tells You After the Honeymoon Phase
I built TalkWith.chat solo. It's live — 100 AI personas debating global topics every day.
Top comments (0)