The monolithic web application had a good run. For most of the 2010s, it was the
default: a single server rendering every page, a JavaScript bundle shipped to every
browser, and a deploy pipeline that treated the entire codebase as one indivisible
unit. It worked. And then it started to crack.

Today, the frontier looks radically different. Rendering has fragmented across four
distinct locations — server, edge, client, and pre-render — and teams are discovering
that choosing where computation happens is as important a design decision as
choosing what computation to do.

The Rendering Renaissance

Modern frameworks no longer ask "SSR or SPA?" — they ask which parts of your
application benefit from which rendering mode. This is the core insight behind the
Islands Architecture popularised by Astro, and the "use client" / "use server"
directives in React Server Components.

Server Components vs. Client Components

React Server Components execute exclusively on the server (or at build time). They
can directly access databases, file systems, and secrets without exposing them to the
browser. They produce a serialised wire format — not HTML, not JSON, but a new React
protocol — that the client runtime can reconcile with existing state.

// app/products/page.tsx — Server Component (no "use client")
import { db } from '@/lib/db'
import { ProductCard } from './product-card'   // Client Component

export default async function ProductsPage() {
  // Direct DB call — never reaches the browser
  const products = await db.query(`SELECT * FROM products ORDER BY rank`)

  return (
    <section>
      {products.map(p => (
        <ProductCard key={p.id} product={p} />  // hydrated on client
      ))}
    </section>
  )
}

Edge Runtimes & the Global Compute Layer

The "edge" is no longer just a CDN trick. Platforms like Cloudflare Workers,
Vercel Edge Functions, and Fastly Compute@Edge run V8 isolates — stripped-down
JavaScript environments — at 300+ PoPs worldwide. Round-trip time from a user in
Mumbai to a PoP in their city is 5–15 ms. To a US-east origin server, it's 180–220 ms.

The network is the bottleneck. Every millisecond of latency you can eliminate at
the infrastructure level is a millisecond your product team doesn't have to optimise
away in code.

— Guillermo Rauch, Vercel CEO, JSWorld 2025

What runs well at the edge — and what doesn't

Islands Architecture

Jason Miller coined "Islands Architecture" in 2020, and it remains the clearest mental
model for partial hydration. The idea: your page is an ocean of static HTML. Interactive
components are islands — isolated, independently hydrated, carrying their own JavaScript
payload. Everything else ships zero JS.

Implementing islands in Astro

---
// src/pages/blog/[slug].astro
import { getPost } from '../lib/cms'
import ShareButton   from '../components/ShareButton.jsx'   // React
import CommentBox    from '../components/CommentBox.svelte'  // Svelte

const { slug } = Astro.params
const post = await getPost(slug)
---

<article>
  <h1>{post.title}</h1>
  <div set:html={post.body} />  <!-- static, zero JS -->

  <ShareButton client:idle url={Astro.url} />   <!-- hydrate when idle -->
  <CommentBox  client:visible postId={post.id} /> <!-- hydrate on scroll -->
</article>

Streaming HTML & Suspense

HTTP streaming isn't new — chunked transfer encoding has existed since HTTP/1.1. What
is new is framework-level support for streaming component trees, letting the
server flush critical HTML first and defer slower data-dependent sections.

React 18's <Suspense> boundary, combined with Next.js's streaming
layout system, allows a page's shell — nav, hero, layout skeleton — to reach the browser
in under 50 ms while slower sections (personalised recommendations, inventory data)
stream in as their data resolves.

Modern Deployment Checklist

Before shipping a new architecture to production, work through this checklist:

1. Audit your rendering modes

   Map each route to its rendering strategy: static, SSR, ISR, or edge. Document the
   decision rationale — data freshness requirements, personalisation needs, cache TTL.

2. Measure Cold Start Latency

   Serverless and edge functions have cold starts. Benchmark P99 latency under realistic
   traffic patterns before committing to a provider. Cloudflare Workers are consistently
   fast; some AWS Lambda runtimes are not.

3. Set Hydration Budgets

   Define a JS budget per page type. A marketing landing page should ship <30 kB JS.
   An interactive dashboard can afford more but should still lazy-load non-critical paths.

4. Configure Cache Headers Explicitly

   Never rely on framework defaults for production. Set
   Cache-Control, Surrogate-Control, and
   Vary headers deliberately for every route and asset type.

5. Instrument Core Web Vitals

   Ship Real User Monitoring (RUM) from day one. LCP, INP, and CLS degrade in
   unexpected ways under real network conditions. Synthetic tests will not catch all
   regressions.

Where We're Headed

The next frontier is compiler-driven architecture. Frameworks like
Svelte 5 (with its Runes system) and Solid.js have demonstrated that reactivity can be
resolved at compile time rather than runtime, eliminating the virtual DOM overhead
entirely. React's compiler (previously React Forget) brings similar optimisations to the
world's largest framework ecosystem.

Alongside this, the emergence of WASM at the edge — running Rust,
Python, or Go modules in Cloudflare Workers — promises to push compute that previously
required a regional server into a globally distributed, millisecond-latency environment.

The monolith isn't dead. But it has been joined by a richer vocabulary of architectural
primitives. The teams winning on performance in 2026 are the ones who understand which
tool to reach for — and why.