| name | frontend |
| description | Frontend architecture approaches — from Multi-Page Apps through Single Page Apps, Server-Side Rendering, Islands Architecture, and Micro-Frontends. Covers the full spectrum of client-side concerns: routing, state management, data fetching, code splitting, and hydration.
USE FOR: frontend architecture selection, comparing SPA vs SSR vs micro-frontends, choosing frontend frameworks, client-side architecture decisions
DO NOT USE FOR: specific rendering approach details (use sub-skills: spa, pwa, micro-frontends, ssr), backend architecture (use dev/backend), design system components (use design-system)
|
| license | MIT |
| metadata | {"displayName":"Frontend Architecture","author":"Tyler-R-Kendrick"} |
| compatibility | claude, copilot, cursor |
| references | [{"title":"MDN Web Docs — Web Technology for Developers","url":"https://developer.mozilla.org/en-US/docs/Web"},{"title":"web.dev — Building for the Modern Web","url":"https://web.dev/"}] |
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
| Criteria | SPA | SSR | SSG | Islands |
|---|
| First Contentful Paint | Slow (JS must load) | Fast (server HTML) | Fastest (CDN) | Fast (static + partial JS) |
| Time to Interactive | Moderate | Moderate (hydration) | Fast | Fast (minimal JS) |
| SEO | Poor (without SSR/prerender) | Excellent | Excellent | Excellent |
| Dynamic Content | Excellent (API-driven) | Excellent (per-request) | Limited (build-time) | Moderate |
| JS Bundle Size | Large | Large (hydration) | Small-Medium | Minimal |
| Caching | API-level | Page-level (CDN w/ ISR) | Full CDN | Full CDN + selective |
| Complexity | Moderate | High | Low | Low-Moderate |
| Best For | Dashboards, apps | Content + interactivity | Blogs, docs, marketing | Content-heavy + some interactivity |
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
| Framework | Type | Rendering | Language |
|---|
| React | Library | SPA, SSR (via Next.js) | TypeScript/JSX |
| Vue | Framework | SPA, SSR (via Nuxt) | TypeScript/SFC |
| Angular | Framework | SPA, SSR (Angular Universal) | TypeScript |
| Svelte | Compiler | SPA, SSR (via SvelteKit) | TypeScript/Svelte |
| Solid | Library | SPA, SSR (via SolidStart) | TypeScript/JSX |
| Astro | Meta-framework | Islands, SSG, SSR | Any (React, Vue, Svelte, etc.) |
| Next.js | Meta-framework | SSR, SSG, ISR, RSC | TypeScript/React |
| Nuxt | Meta-framework | SSR, SSG, ISR | TypeScript/Vue |
| Remix | Meta-framework | SSR, SPA mode | TypeScript/React |
| SvelteKit | Meta-framework | SSR, SSG, SPA | TypeScript/Svelte |
Architecture Decision Guide
| When You Need... | Choose |
|---|
| Rich interactivity, dashboard-style UI | SPA (see dev/frontend/spa) |
| SEO + interactivity, content sites | SSR (see dev/frontend/ssr) |
| Static content with occasional interactivity | Islands (Astro) |
| Offline support, native-like experience | PWA (see dev/frontend/pwa) |
| Multiple teams, independent deployment | Micro-frontends (see dev/frontend/micro-frontends) |
| Blog, documentation, marketing pages | SSG (Next.js, Astro, or Hugo) |
| Full-stack with tight server integration | Remix or SvelteKit |
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 optimizationdev/frontend/pwa — Progressive Web Apps: service workers, offline support, installabilitydev/frontend/micro-frontends — Micro-Frontend Architecture: Module Federation, single-spa, compositiondev/frontend/ssr — Server-Side Rendering: SSR, SSG, ISR, Islands, React Server Components
