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.
Before you read this
This article is mostly about how the browser side — the screen — works. If IT vocabulary is unfamiliar, reading the primers "How a Web Service Works" and "Programs and APIs" first makes it far easier to follow. You can also look anything up in the glossary as you read.
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.
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 |
How to choose — a 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.
Where the major frameworks sit against that ladder is as follows.
| 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 |
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.
AI decision axes — What to hand to the AI and what to keep in human hands
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.
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.
Pitfalls and forbidden moves
Of the forbidden moves the individual articles cover in detail, here are the six that matter at chapter level.
| Forbidden move | Why it is bad → what to do instead |
|---|---|
| Building an SEO-critical site with CSR only | the crawler reads empty HTML and search traffic collapses |
| Storing a JWT in localStorage | one XSS leaks every user’s token; an httpOnly cookie is mandatory |
| Hand-rolling routing and SSR on plain React | there is no reason not to use Next.js or Astro |
Authorizing on the frontend alone, e.g. user.role === 'admin' | anyone can rewrite it in F12; server-side authorization is required |
| Serving images at their original size | the classic way to wreck LCP; convert automatically with next/image or the equivalent |
| Leaving CSS until later | class-name collisions and duplicated styles blow up the cost of every later change |
Author’s note — the search traffic that “modern, therefore” broke
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.
What you must decide — what’s your project’s answer?
For each item, articulate your project’s answer in 1-2 sentences.
Rendering and 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, authentication and 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 and 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 |
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.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (36/95)