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.
A full list of all articles in this category, with summaries and learning points, is available at the following page.
What is frontend architecture in the first place
Imagine a restaurant’s service counter. No matter how wonderful the kitchen (backend) cooks, if service at the counter is slow, the menu is unreadable, and the ordering process is confusing — customers never come back.
Frontend architecture is the domain that handles the design of every screen, interaction, and display that users directly touch. It systematizes the technical decisions affecting user experience — rendering methods, framework selection, state management, CSS design, hosting, and more.
Without frontend architecture, no matter how perfect the backend is, the system ends up slow to render, hard to use, and visually inconsistent — unused.
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
| 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 | 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 | 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 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 / 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.
Knowledge structure of this category
This category is composed of 9 articles in total. The structure progresses from foundation to surface, then to cross-cutting themes.
Foundation (Group 1) is decided in the order hosting -> rendering method -> framework selection. Once you know whether you’re distributing via CDN or running at the edge, the available rendering methods narrow, and framework options follow automatically.
Surface (Group 2) picks state management and CSS design on top of the chosen framework. React pairs with Zustand; Astro’s SSG base minimizes state management — tightly coupled with the FW.
Cross-cutting themes (Group 3) — BFF, auth, SEO — are connection surfaces with other categories. BFF pairs with API design in software architecture; auth pairs with authentication design in security architecture.
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 |
| Assuming “all frameworks are basically the same” | Philosophies differ, productivity varies 2-3x. Choose by team skill and use case |
| Deferring CSS design | Class-name collisions and style duplication explode refactor cost at scale. Design from the start |
The frontend is the only layer that reaches the user. Treat Core Web Vitals as a business requirement.
AI decision axes
| AI-era favorable | AI-era unfavorable |
|---|---|
| React + Tailwind + shadcn/ui (mainstream) | Custom UI / in-house design system |
| Next.js / Astro (mature) | Niche / emerging frameworks |
| Type safety (TypeScript + Zod) | Plain JavaScript |
| Server Components, file-based routing | Custom routing, complex state management |
- 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)
The boundary between AI-written and human-owned areas
The areas where AI can write frontend code with high accuracy are: data-fetching logic, form validation, API integration, and basic UI component implementation. Layout with Tailwind utility classes and placement of shadcn/ui components are also handled nearly accurately by AI.
On the other hand, branding-related design decisions, comprehensive accessibility coverage, animation fine-tuning, and UX design informed by user research remain in the human domain. Even if AI can produce a “working UI,” whether it’s a “usable UI” is a separate question — humans need to keep that judgment.
Mainstream stack and AI generation accuracy
The combination of React + TypeScript + Tailwind CSS is the frontend stack with the highest AI generation accuracy as of 2026. There are overwhelmingly more implementation examples of this combination in GitHub codebases, and AI can produce standard code covering naming patterns, directory structures, and even test authoring.
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)