About this article
This article is the entry point of the “Frontend Architecture” category in the Architecture Crash Course for the Generative-AI Era series, surveying the domain.
The frontend is “the only place users actually touch.” No matter how perfect the backend is, if the UI trips users up the system goes unused. This article surveys why we treat it as its own domain, the rendering taxonomy, the placement of major frameworks, a page-type × configuration ladder, and the AI-era benefits structure.
More articles in this category
The only layer that reaches the user
Developers tend to focus design effort on the backend to satisfy functional and non-functional requirements, but for consumer-facing products “UX matters at a level directly tied to business outcomes.” Treating the frontend as “the cosmetic layer” is the same as dismissing business value.
No matter how functional the system is, a system users don’t use may as well not exist.
Why treat it as a separate architecture
1. The tech stack has evolved separately
Frontend-specific frameworks (React, Vue.js, Angular), build tools (Vite, Turbopack), state managers (Redux, Zustand) — a “different tech culture” has formed compared to backend.
2. UX requirements are orthogonal to functional requirements
Page load speed (LCP — Largest Contentful Paint), input responsiveness (INP — Interaction to Next Paint), layout stability (CLS — Cumulative Layout Shift) — UI-specific non-functional requirements that backend can’t see.
3. Change frequency and blast radius differ
Changes far more frequently than business logic, and small changes hit user experience directly.
Rendering taxonomy
flowchart LR
USER([User]) --> EDGE[CDN/Edge]
EDGE --> RENDER{Rendering}
RENDER -->|Per nav,<br/>server-generated| MPA[MPA<br/>WordPress/Rails]
RENDER -->|One HTML, JS swaps| SPA[SPA<br/>React CSR/Vue]
RENDER -->|Per request,<br/>server-generated| SSR[SSR<br/>Next.js/Nuxt]
RENDER -->|Static at build| SSG[SSG<br/>Astro/Next static]
RENDER -->|Static + partial regen| ISR[ISR<br/>Next.js]
classDef user fill:#fef3c7,stroke:#d97706;
classDef edge fill:#f0f9ff,stroke:#0369a1;
classDef classic fill:#f1f5f9,stroke:#64748b;
classDef modern fill:#dbeafe,stroke:#2563eb;
classDef static fill:#dcfce7,stroke:#16a34a;
class USER user;
class EDGE edge;
class MPA classic;
class SPA,SSR modern;
class SSG,ISR static;| Approach | Description | Examples |
|---|---|---|
| MPA (Multi Page App) | Server generates HTML on each navigation | WordPress, traditional Rails |
| SPA (Single Page App) | One HTML, JS swaps the view | React CSR, Vue.js |
| SSR | Server generates HTML per request | Next.js, Nuxt.js |
| SSG | HTML generated at build time | Astro, Next.js Static |
| ISR (Incremental Static Regeneration) | Hybrid of SSR and SSG | Next.js |
What you must decide — what’s your project’s answer?
For each item, articulate your project’s answer in 1-2 sentences.
Rendering / tech stack
| Item | Examples |
|---|---|
| Hosting | CDN, edge compute |
| Rendering | MPA / SPA / SSR / CSR / SSG |
| State management | Context / Redux / Zustand / Jotai |
| CSS | CSS Modules / Tailwind / CSS-in-JS |
| Framework | React / Vue.js / Angular / Svelte |
| BFF (Backend For Frontend) | GraphQL / REST / tRPC (typed APIs in TypeScript end-to-end) |
Routing / auth / accessibility
| Item | Examples |
|---|---|
| Routing | File-based / Config-based |
| Auth | Cookie / LocalStorage / Refresh Token (long-lived token used to mint new access tokens without re-login) |
| Naming | BEM (Block Element Modifier — CSS naming convention), kebab-case, etc. |
| Directory layout | feature-based / layer-based |
| URL paths | RESTful / hierarchical / query design |
| Accessibility | WCAG (Web Content Accessibility Guidelines) compliance, ARIA (Accessible Rich Internet Applications) |
i18n / SEO / security / performance
| Item | Examples |
|---|---|
| i18n | next-intl / react-i18next |
| Supported environments | Browsers / OS / screen-size range |
| SEO | Meta tags / OGP (Open Graph Protocol) / structured data / sitemap |
| Security | CSP (Content Security Policy) / XSS prevention / CSRF prevention |
| Error handling | Validation / Error Boundary |
| Performance | Core Web Vitals (LCP / INP / CLS) / image optimization |
Where major frameworks sit
| FW | Strengths | Fits |
|---|---|---|
| React | Largest ecosystem, most jobs | General mid-to-large web apps |
| Vue.js | Low learning cost, HTML-friendly | Small/mid scale, gradual adoption |
| Angular | Full-featured, TypeScript-default | Large enterprise, robustness focus |
| Svelte | Lightweight, no runtime | Performance focus, small scale |
| Next.js | React-based, SSR/SSG | SEO-focused web apps |
| Astro | Content-focused, fast SSG | Blogs, LPs, docs |
A search-traffic disaster from “modern, therefore” (industry case)
A media-site relaunch project decided to “rebuild every page in React CSR (SPA)” for the sole reason of “because it’s modern.” Three months after launch, organic search traffic was cut in half. The cause was simple: OGP and meta tags only entered the HTML after JS executed, and crawlers (search engines and social media share crawlers) were “reading empty HTML.” No thumbnails appeared, and even shared links got no clicks.
There are similar stories of personal bloggers around 2017 impulsively making their site a SPA, then opening Search Console six months later in cold sweat at the visible drop in traffic. Astro-style SSG frameworks weren’t mature yet, so the standard ending was “we went back to WordPress.”
Picking technology because “it’s trending” or “it’s modern” punches you twice afterward — UX and business metrics. Building content-centric sites (blogs, LPs, media) on SPA is a textbook landmine — SEO and initial render are catastrophically weak. The current default is to choose method per page (articles SSG, admin SPA, etc.) — both “all SPA” and “all SSR” are sloppy.
“Modern = correct” is wrong. Pick the method per use case — that is the foundation of frontend design.
Page-type × configuration ladder
Note: industry rates as of April 2026. They will go stale, so periodic refresh is needed.
“One method for the whole site” is a recipe for breakdown. Choosing per page type is the standard.
| Page type | Rendering | Hosting | State | Core Web Vitals |
|---|---|---|---|---|
| Blog / docs | SSG (Astro) | Cloudflare Pages | useState | LCP < 2s |
| LP / marketing | SSG | Vercel / Netlify | useState | LCP < 2.5s |
| E-commerce product detail | ISR (60-300s) | Vercel | Zustand + TanStack Query | LCP < 2.5s |
| SaaS dashboard | CSR | Vercel / private CDN | Zustand + TanStack Query | INP < 200ms |
| Login-required admin | CSR | Private CDN | Zustand + TanStack Query | INP < 200ms |
| News / media | ISR + Streaming SSR | Vercel | TanStack Query | LCP < 2.5s |
Core Web Vitals “Good” range (LCP < 2.5s, INP < 200ms, CLS < 0.1) is the Google SEO bar. The evaluation axis: “75% of page views inside the Good range.”
“All-page SSR” is a time bomb. The classic incident is exhausting your Vercel function-execution quota. Design Static First.
Architecture-level traps
| Forbidden move | Why |
|---|---|
| CSR-only on an SEO-required site | JS execution lags days to weeks, organic traffic crashes |
| JWT in localStorage | XSS instantly leaks every user’s token; httpOnly Cookie required |
| Hand-rolled routing / SSR on raw React | No reason not to use Next.js / Astro |
| Tailwind without configuration | Design Tokens don’t apply, color/spacing drift |
| Serving images at native size | Classic LCP killer — Next/Image auto-optimizes |
| Adopting CSS-in-JS in an RSC environment | styled-components went into maintenance mode in 2024 |
Frontend-only authorization with user.role === 'admin' | Editable in DevTools — server authorization required |
Same fact stored twice (items and itemCount) | One will go stale; derived state must be computed |
| 10+ useState for a single form | React Hook Form solves it |
| Checking WCAG 2.2 AA only by eye | Add axe-core + Lighthouse to CI |
The frontend is the only layer that reaches the user. Treat Core Web Vitals as a business requirement.
The AI-era lens
With AI-driven development as the assumption, the frontend dramatically benefits as “a domain where AI can write the UI directly.” AI tools — v0, Bolt, Lovable — instantly produce React/Tailwind/shadcn code, and the more mainstream your stack, the better the generation quality.
| AI-era favorable | AI-era unfavorable |
|---|---|
| React + Tailwind + shadcn/ui (copy-paste reusable component library) (mainstream) | Custom UI / in-house design system |
| Next.js / Astro (mature) | Niche / emerging frameworks |
| Type safety (TypeScript + Zod — schema validation library) | Plain JavaScript |
| Server Components, file-based routing | Custom routing, complex state management |
UI/UX design is AI’s strong suit, but “branding, user context, accessibility” still need human judgment. AI can mass-produce patterns, but “deciding why this screen looks this way is human work.”
Common misreadings
- “All frameworks are basically the same” → React, Vue, Svelte, Astro have different philosophies; “team skill × use case fit” changes productivity by 2-3x. Picking by trend hurts hiring and maintainability.
- “SPA solves everything” → SPA gives great interaction, but SEO and first render are weak. SPA on a blog or LP wipes out organic traffic. Per-page choice is the modern default.
- “CSS can be done later” → CSS design is where the biggest difference shows up at scale. Postponing means “class-name collisions and style duplication explode the refactor cost.”
- “Frontend is easy, perfect for new hires” → LCP, INP, CLS, accessibility, XSS prevention — it’s a “concentrated specialty.” Treating it lightly breaks UX in production.
How to make the final call
Frontend architecture is “the only layer touching the user directly,” and no matter how solid the backend is, a rough UI/UX produces an unused system. The core of selection is reasoning backward from “what user experience do we want”, not from “functional requirements.”
SPA vs SSR vs SSG, Context vs Redux, Tailwind vs CSS Modules — none of those are decided by isolated technical merit. LCP, INP, CLS — UX metrics — must be treated as part of the business requirements. The frontend changes frequently; “small changes punch the user directly”, so reconciling change-friendliness with stability is constant.
The decisive axis is “lean into AI’s strong suit.” v0, Bolt, Lovable, Cursor, Claude Code — AI tools that produce frontend code directly are now production-ready. Picking the mainstream stack of React + TypeScript + Tailwind + shadcn/ui + Next.js (or Astro) alone makes “development speed differ by an order of magnitude.”
Conversely, niche frameworks, custom design systems, and plain JavaScript drop AI’s accuracy and cost effort. AI can write up to “patternized UI”; “branding, accessibility, user context remain human work.” Splitting “let AI mass-produce this” from “humans decide this” is the modern frontend stance.
Selection priority:
- Backward from UX metrics (LCP, INP, CLS as business requirements).
- Lean on the mainstream stack (React + TS + Tailwind + Next/Astro is the default).
- Type safety end to end (TypeScript + Zod to make contracts explicit).
- Split AI-written portions vs human-decided portions (branding and A11y stay human).
Summary
This article served as the entry point of the “Frontend Architecture” category, surveying the domain.
Reason backward from user experience, lean on the mainstream stack, separate AI-written portions from the human territory. Three cores of frontend architecture.
The next article opens the deep dive: hosting (CDN, edge).
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (30/89)