Frontend Architect Glossary
How to use this glossary
This glossary defines terms the way a frontend architect should use them in decisions, reviews, and technical narratives. The goal is not textbook precision; it is shared working vocabulary.
Use each term in three ways:
- Decision: what choice does this term help clarify?
- Confusion: what mistake does this term often hide?
- Evidence: what artifact, metric, or review proves the concept is handled?
Architecture and decision terms
| Term | Working definition |
|---|---|
| ADR | Architecture Decision Record: a short document capturing context, decision, alternatives, tradeoffs, verification, and follow-up. |
| Fitness function | An automated or reviewable signal that proves an architecture constraint is still holding. |
| NFR | Non-functional requirement: performance, reliability, accessibility, security, privacy, maintainability, cost, or operability requirement. |
| Reversibility | How easily a decision can be changed after adoption. Hard-to-reverse decisions deserve heavier review. |
| Bounded context | A product capability area with its own language, ownership, data rules, and change reasons. |
| Strangler migration | Incremental migration where new slices replace old behavior without a big-bang rewrite. |
| Review packet | A reusable review artifact with intake questions, required evidence, red flags, and approval criteria. |
| Constraint register | A small table of NFRs, owners, verification signals, and review triggers for a route or surface. |
| Risk class | A proportional category that determines review depth, gates, rollback, and operating rigor. |
| Reference architecture | A reusable blueprint that captures common product forces, defaults, risks, and review checks. |
| Diagram pack | Reusable visual notation for explaining route, cache, observability, trust, GenUI, and package boundaries. |
Rendering and data terms
| Term | Working definition |
|---|---|
| CSR | Client-side rendering: browser receives a shell and builds most UI with JavaScript. |
| SSR | Server-side rendering: HTML is generated per request or server execution. |
| SSG | Static site generation: HTML is produced ahead of time and served from static infrastructure. |
| ISR/revalidation | Static output refreshed after build according to time or invalidation rules. |
| Hydration | Client work required to attach interactivity to server-rendered or static HTML. |
| Partial hydration | Hydrating only interactive regions instead of the entire page. |
| Islands architecture | Page architecture where static content surrounds isolated interactive islands. |
| RSC | React Server Components: React components rendered on the server with explicit client boundaries. |
| Server state | Data owned by a backend or external source, usually cached and invalidated. |
| URL state | State encoded in route path or search params, useful for shareable navigation. |
| Form state | User-entered in-progress data, validation, dirtiness, and submission state. |
| Optimistic update | UI updates before server confirmation, with rollback or reconciliation behavior. |
Performance terms
| Term | Working definition |
|---|---|
| LCP | Largest Contentful Paint: measures when the main visible content becomes useful. |
| INP | Interaction to Next Paint: measures responsiveness of user interactions. |
| CLS | Cumulative Layout Shift: measures unexpected visual movement. |
| TTFB | Time to First Byte: time until the first response byte is received. |
| Long task | Main-thread work that blocks responsiveness long enough to harm interactions. |
| Critical rendering path | Browser steps and resources needed before useful pixels appear. |
| Performance budget | Explicit limits for metrics, bytes, requests, scripts, or interaction cost. |
| RUM | Real User Monitoring: field measurement from actual user sessions. |
| Synthetic monitoring | Controlled lab measurement from scripted environments. |
Security and reliability terms
| Term | Working definition |
|---|---|
| CSP | Content Security Policy: browser policy limiting where scripts/resources can load and execute. |
| Trusted Types | Browser mechanism that restricts dangerous DOM sinks to approved policies. |
| XSS | Cross-site scripting: attacker-controlled content executes or affects browser behavior. |
| CSRF | Cross-site request forgery: attacker causes a user browser to submit unwanted state-changing requests. |
| CORS | Browser mechanism controlling cross-origin reads; not an authorization system. |
| Clickjacking | Tricking users into interacting with a framed page. |
| Tabnabbing | External pages manipulating the opener window. |
| Passkey | Passwordless credential based on WebAuthn public-key authentication. |
| Degraded state | Intended UI behavior when a dependency is slow, unavailable, or partial. |
| Error budget | Accepted amount of unreliability before release velocity or priorities change. |
Design system terms
| Term | Working definition |
|---|---|
| Design token | Named design decision such as color, spacing, typography, radius, or motion. |
| Semantic token | Token named by intent rather than raw value, such as color.action.primary. |
| Primitive | Low-level accessible component with behavior contract. |
| Headless component | Behavior and accessibility without fixed styling. |
| Component contract | Public API plus accessibility, state, theming, and compatibility obligations. |
| Theming | Mapping semantic system decisions to brand, mode, density, or product variation. |
| Deprecation window | Time and migration path before removing a supported API/component. |
AI, GenUI, and agent terms
| Term | Working definition |
|---|---|
| GenUI | Generative UI: AI-assisted selection/composition of approved UI components. |
| Component registry | Approved set of components and schemas an AI system may request. |
| A2UI | Declarative AI-to-UI payload concept for rendering generated UI safely. |
| AG-UI | Agent-to-user interface event pattern for streaming agent progress and UI updates. |
| RAG | Retrieval-Augmented Generation: grounding model output in retrieved sources. |
| Vector store | Index optimized for semantic retrieval through embeddings. |
| Citation contract | UI and data rule requiring answer evidence to be visible and inspectable. |
| MCP | Model Context Protocol: protocol pattern for connecting AI systems to tools/data. |
| A2A | Agent-to-Agent protocol pattern for delegation between independent agents. |
| Tool risk class | Classification that determines whether a tool can auto-run, needs approval, or is forbidden. |
| Eval | Test or judgment process that measures AI behavior before and after release. |
| Prompt injection | Malicious or conflicting content that tries to override system or product instructions. |
Source lens
Use the Future Radar and Guide Maintenance sections for terms that change quickly, especially browser APIs, React rendering features, and AI protocols.
Common confusions
| Confusion | Better framing |
|---|---|
| SSR means fast | SSR can improve first content, but hydration, data waterfalls, caching, and server latency still decide user experience. |
| RSC is a security boundary | Server Components can reduce client exposure, but authorization, validation, and sensitive-data handling still need explicit controls. |
| CORS is authorization | CORS controls browser cross-origin reads. It does not decide whether a user may access data. |
| Accessibility means ARIA | Accessibility starts with semantics, keyboard, focus, names, states, errors, motion, contrast, and workflow completion. |
| RUM replaces profiling | RUM shows real-user symptoms. Profiling explains local causes. Mature teams need both. |
| Design system means component library | A design system is a governed UI platform: tokens, primitives, contracts, packages, migration, adoption, and ownership. |
| Optimistic update means success | Optimistic UI is pending local feedback until the server confirms or rejects. |
| Edge cache means public cache | Edge delivery can be private, varied, or no-store. Cacheability depends on data classification. |
| Human approval makes AI tool use safe | Approval is one control. Server policy, authorization, idempotency, audit, evals, and kill switches still matter. |
| Telemetry means log everything | Observability must minimize sensitive data and collect signals that support decisions and incidents. |
Decision reference
| If deciding about | Check these terms | Related guide areas |
|---|---|---|
| architecture decision | ADR, reversibility, constraint register, risk class, fitness function | part-0/architect-decision-making-model, Part I ADRs |
| reading an existing system | bounded context, ownership, route inventory, quality signal | part-0/reading-existing-frontend-system, Part IV |
| rendering strategy | CSR, SSR, SSG, hydration, RSC, partial hydration, islands | part-iii/part-iii-rendering-data-map, system-design interviews |
| mutation design | server state, form state, optimistic update, idempotency, degraded state | Part 0, Part III, Part XII |
| performance plan | LCP, INP, CLS, TTFB, long task, budget, RUM, synthetic | Part VI, performance capstone, high-traffic funnel reference |
| browser security | CSP, Trusted Types, XSS, CSRF, CORS, clickjacking, tabnabbing | Part VIII, secure account portal capstone |
| design-system architecture | token, semantic token, primitive, headless, component contract | Part VII, design-system reference architecture |
| GenUI launch | component registry, citation contract, tool risk class, eval, prompt injection | Part XIII, GenUI reference architecture |
| offline-first design | server state, optimistic update, degraded state, idempotency | offline-first reference architecture and system-design prompt |
| microfrontend decision | bounded context, coupling, ownership, compatibility, fitness function | microfrontend reference architecture and Part IV |
Reference architecture index
| Product surface | Starting blueprint | Primary artifacts |
|---|---|---|
| SaaS dashboard | reference-architectures/saas-dashboard | route matrix, data ownership map, failure matrix |
| Ecommerce frontend | reference-architectures/ecommerce-frontend | cache policy, script register, checkout readiness review |
| Design system platform | reference-architectures/design-system-platform | token taxonomy, component contract, adoption scorecard |
| Microfrontend platform | reference-architectures/microfrontend-platform | boundary ADR, compatibility matrix, shell contract |
| GenUI copilot UI | reference-architectures/genui-copilot-ui | registry contract, tool-risk policy, eval matrix |
| Offline-first field app | reference-architectures/offline-first-field-app | local data map, mutation queue, conflict policy |
| High-traffic funnel | reference-architectures/high-traffic-marketing-funnel | performance budget, variant cache plan, script kill-switch matrix |
Practice index
| Practice need | Start here |
|---|---|
| explain architecture visually | diagrams/frontend-architecture-diagram-pack |
| practice under interview timing | system-design-interviews/frontend-architect-interview-workbook |
| compare blueprint to final artifact | reference-architectures/reference-architecture-worked-solutions |
| improve source quality | meta/source-backed-reading-notes |
Artifact reference
| Term family | Artifact that proves it |
|---|---|
| architecture decision | ADR or RFC with alternatives and verification |
| rendering/data | route rendering matrix and data ownership map |
| performance | route budget, trace, and RUM dashboard |
| accessibility | component accessibility contract and keyboard/focus walkthrough |
| security/privacy | threat model, data-flow map, third-party register, CSP plan |
| reliability | failure matrix, degradation plan, incident runbook |
| design system | API review, token taxonomy, adoption scorecard |
| GenUI | eval matrix, registry contract, trace schema, kill-switch matrix |