Frontend

Frontend Architecture

Overview

Frontend architecture has evolved far beyond "put jQuery on the page." Modern frontend development is a spectrum of rendering strategies, each with distinct tradeoffs for performance, SEO, developer experience, and user experience. Choosing the right architecture is one of the most consequential decisions in a web project — it affects everything from time-to-interactive to team structure.

The Frontend Architecture Spectrum

┌──────────────────────────────────────────────────────────────────────┐
│                    Frontend Architecture Spectrum                     │
│                                                                      │
│  MPA ────▶ SPA ────▶ SSR ────▶ SSG ────▶ Islands ────▶ Micro-FEs   │
│                                                                      │
│  Server      Client       Server+Client    Build-Time   Partial     │
│  Rendered    Rendered     Hybrid           Pre-render   Hydration   │
│  Full page   Single       HTML+Hydrate     Static HTML  Interactive │
│  reloads     shell+API    on every req     + CDN        islands     │
└──────────────────────────────────────────────────────────────────────┘

Multi-Page Application (MPA)

Traditional server-rendered HTML pages. Each navigation is a full page request. Simple, SEO-friendly, but no client-side interactivity without additional JavaScript.

Single Page Application (SPA)

A single HTML shell with client-side routing and rendering. The server provides JSON APIs; the browser handles everything else. Rich interactivity but challenges with SEO, initial load, and bundle size.

Server-Side Rendering (SSR)

HTML is rendered on the server for each request, then hydrated on the client for interactivity. Best of both worlds — SEO-friendly first paint with SPA-like interactivity after hydration.

Static Site Generation (SSG)

Pages are pre-rendered at build time and served as static HTML from a CDN. Fastest possible TTFB, but content is only as fresh as the last build.

Islands Architecture

The page is mostly static HTML with isolated "islands" of interactivity that hydrate independently. Only interactive components ship JavaScript. Astro pioneered this approach.

Micro-Frontends

Multiple independently deployed frontend applications composed into a single user experience. Each team owns a vertical slice of the UI with its own tech stack, build pipeline, and deployment.

Comparison Table

Core Frontend Concerns

Routing

• Client-side: React Router, Vue Router, Angular Router — URL changes without full page reloads
• File-based: Next.js, Nuxt, SvelteKit, Remix — filesystem structure defines routes
• Server-side: Traditional MPA routing — each URL is a server request

State Management

• Local state: React useState/useReducer, Vue ref/reactive, Svelte stores, Angular signals
• Global state: Redux, Zustand, Pinia, NgRx, Jotai, Valtio
• Server state: TanStack Query, SWR, Apollo Client — treats server data as a cache
• URL state: Search params as state (Remix philosophy)

Data Fetching

• Client-side: fetch/axios from useEffect, TanStack Query, SWR
• Server-side: Next.js Server Components, Remix loaders, Nuxt useFetch, SvelteKit load
• GraphQL: Apollo Client, urql, Relay
• Real-time: WebSockets, Server-Sent Events, tRPC subscriptions

Code Splitting

• Route-based: React.lazy + Suspense, dynamic import()
• Component-based: Loadable Components, Vue async components
• Framework-managed: Next.js automatic splitting, Vite's chunk optimization

Hydration

• Full hydration: Entire page re-rendered on client (React SSR, Next.js)
• Partial hydration: Only interactive parts hydrate (Astro Islands)
• Progressive hydration: Components hydrate on visibility/interaction
• Resumability: Skip hydration entirely, serialize state (Qwik)

Framework Landscape

Architecture Decision Guide

Performance Budgets

A well-architected frontend should target:

• Largest Contentful Paint (LCP): < 2.5s
• First Input Delay (FID): < 100ms
• Cumulative Layout Shift (CLS): < 0.1
• Total JS bundle (initial): < 200KB gzipped
• Time to Interactive (TTI): < 3.5s on 4G

Best Practices

• Choose the simplest architecture that meets your requirements — not every app needs SSR or micro-frontends.
• Measure performance with real user metrics (Core Web Vitals), not just Lighthouse scores.
• Use code splitting aggressively — no user should download JavaScript they will never execute.
• Treat server state and client state differently — use TanStack Query or SWR for server state, not Redux.
• Design for progressive enhancement — the page should be usable before JavaScript loads.
• Consider the Islands Architecture for content-heavy sites that need sprinkles of interactivity.

Sub-Skills

• dev/frontend/spa — Single Page Applications: client-side routing, state management, bundle optimization
• dev/frontend/pwa — Progressive Web Apps: service workers, offline support, installability
• dev/frontend/micro-frontends — Micro-Frontend Architecture: Module Federation, single-spa, composition
• dev/frontend/ssr — Server-Side Rendering: SSR, SSG, ISR, Islands, React Server Components