--- 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 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