FoundationsGENERALPLATFORM-SPECIFIC
What the Frontend Is Responsible For
The boundary that keeps this domain honest: the browser-executed application and the interaction a person feels — and where everything else properly lives.
The intent, the obvious build, and why it breaks
Every lesson starts where the work starts: someone wanted an outcome, and the first implementation that comes to mind has a problem.
The question
Which of these problems is mine, which belongs to a neighbour, and which is shared?
The user intent
A team wants to ship a feature. Half the arguments about how are really arguments about whose problem a given part is.
The obvious build
Frontend is everything the user sees. If it appears on screen, it is a frontend problem; if it does not, it is not.
Why it breaks
Authorization appears on screen — a hidden button is visible UI — and is emphatically not a frontend responsibility to enforce (Authorization-Aware UI).
How it breaks in a real browser
- Authorization appears on screen — a hidden button is visible UI — and is emphatically not a frontend responsibility to enforce (Authorization-Aware UI).
- Slow page loads often have nothing to do with frontend code and everything to do with server response time or a cache miss (Server-Side Rendering).
- A UI that is complicated because the API returns the wrong shape is an API design problem being paid for in component code (How API Shape Drives UI Complexity).
- Treating everything visible as ours produces a team that owns no boundaries and re-implements three neighbouring domains badly.
Intent→Event→State→UI Logic→DOM Work→Network→Layout / Paint→Pixels→Feedback
What is actually happening
In the browser, not in the framework.
- The frontend owns the browser-executed application: what runs on the user's device, what it renders, how it responds, and what it does when things fail.
- It owns the interaction contract with the person: reachability, feedback, error presentation, and whether the interface tells the truth about what has happened.
- It owns client-side state and its synchronisation with an authority it does not control (State Synchronization).
- It owns what is delivered to the browser — bytes, execution cost, and the strategy that decides when the page is usable (Choosing a Rendering Strategy).
- It shares performance with Observability, security with Security Engineering, and the contract with API Design. Shared means both parties have obligations, not that either can defer.
- It does not own authority. Every rule that matters is enforced server-side; the frontend expresses it, and expressing it is not enforcing it (What the Frontend Is Responsible For in Auth).
What this makes the browser do
And which of it is avoidable.
- Everything in this domain ultimately becomes browser work: bytes to parse, script to execute, nodes to lay out, layers to composite. That is the through-line that makes the boundary concrete rather than organisational.
- When a decision belongs to a neighbouring domain, the frontend still pays for it in browser work — an over-fetching endpoint is paid for in parse time and memory on the device.
The boundary, stated
This table is the domain's scope agreement. When something is contested, the useful question is not "who has capacity" but "who can actually enforce this", and the answer is usually unambiguous.
| Question | Owned by | The frontend's part |
|---|---|---|
| How do requests move between client and server? | Networking | What the browser does with the response, and what blocks on it |
| What contract should the client consume? | API Design | Saying when the contract shape is making the UI worse |
| How is the service implemented and operated? | Backend Engineering | What the client may assume, and what it must never enforce alone |
| How does a JavaScript engine execute this? | Runtime Internals | How the browser schedules that execution against rendering |
| How is source transformed into a bundle? | Compilers | What ships, how much of it, and when it is parsed |
| Where is the bottleneck in production? | Observability & Performance | Collecting the client-side evidence nobody else can see |
| How is this attacked? | Security Engineering | Escaping, CSP, cookie flags, dependencies — the browser-enforced half |
| Where do the static assets live? | Cloud & Infrastructure | Cache headers, content hashing, and what a stale asset does to a running tab |
| How do independent nodes agree? | Distributed Systems | Old tabs, offline queues and version skew, from the client's side |
| Is this interface operable by everyone? | Frontend Engineering | All of it. No other domain can supply it. |
Three arguments this settles
Boundary rules earn their place by resolving real disputes. These three come up on every team, and in each case the resolution follows from where the code runs rather than from who has time.
Contested cases
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| "The button is hidden, so users cannot do it" | A user performs the action anyway, via the API | A UI affordance was mistaken for a control | Hide it *and* enforce server-side. The frontend expresses the rule; the server is the rule (Authorization-Aware UI). |
| "The page is slow, that is a backend problem" | Server timings look fine and the page still feels slow | Time to first byte is one term; parse, execute, hydrate and main-thread contention are others | Attribute with client-side evidence before assigning the problem (Measure Before Optimising). |
| "Just call the four endpoints from the component" | A waterfall of dependent requests; one screen, four failure modes | A missing endpoint being paid for in client code and round trips | Name it as an API shape problem; a BFF exists for exactly this (Backend for Frontend). |
How to build it
Most important first.
- Push authority server-side, always. The client renders the consequences of a decision; it never makes one that matters (Authorization-Aware UI).
- When the UI is fighting the API, fix the API. A component that stitches four calls together to render one screen is describing a missing endpoint (Backend for Frontend).
- Deep-link rather than re-explain. This domain gets worse every time it re-teaches TLS, B-trees or Raft badly.
- Own the user-visible failure story completely. No neighbouring domain will decide what a person sees when a request times out.
Keyboard, focus, semantics, announcement
A required field on every lesson in this domain, not a section added when there is room.
- Accessibility is unambiguously this domain's responsibility. No other domain can supply semantics, focus order, keyboard operability or announcements — they exist only in the markup and behaviour the frontend produces (Semantics Before ARIA).
- It is shared with design in the sense that contrast, motion and target size are design decisions; it is not shared in the sense that the frontend can decline to implement them.
- When a backend constraint makes an accessible pattern hard — a slow endpoint behind an autocomplete, say — the accessible resolution is still a frontend obligation (Accessible Component Patterns).
What can go wrong
Failure modes
- Re-implementing validation client-side and treating it as sufficient. Client validation is a courtesy to the user; the server validates because the client can be bypassed (Native Validation and Its Limits).
- Absorbing backend complexity into components because changing the API is politically harder than adding another
useEffect. - Declaring performance "the backend's problem" when the payload is fine and the main thread is saturated — or the reverse.
- Treating accessibility as a specialist's concern outside the team, which reliably means it is nobody's.
Security
- The frontend owns the browser-enforced half: escaping and sanitization at render time, CSP, cookie flags requested correctly, and not shipping secrets (Cross-Site Scripting).
- It does not own the enforcement half. Any check that only exists in the client is a suggestion.
- It owns the supply chain of what it ships: every dependency and every third-party script executes with full page authority (Third-Party Scripts and the Supply Chain).
Misreads
- "Frontend is the presentation layer." It is an application platform with state, networking, caching, storage, security and concurrency concerns of its own.
- "If it renders, we own it." Authority never renders, and much of what renders is a consequence of decisions made elsewhere.
- "Full-stack means the boundary does not apply." It means one person crosses it. It does not mean the failure modes merge.
Measuring it, and what changes in the field
How you would see this
- Field measurement of what users experience is the frontend's to collect, because only the client can see the device, the network and the interaction (Real User Monitoring).
- Server-side timing tells you when the bytes left. Client-side timing tells you when the person could use the page. Both are needed to attribute a regression (Reading a Network Waterfall).
Slow device, slow network, large data, old tab
- As a team grows, boundary clarity matters more than boundary placement — an explicit, slightly wrong boundary beats an implicit one.
- In a small team where one person owns both sides, the boundary still matters, because the failure modes remain distinct even when the author does not.
What this costs
- A strict boundary means occasionally waiting on another team rather than working around them in component code. The workaround is faster once and slower forever.
- Deep-linking rather than re-teaching means a learner sometimes leaves this domain to understand something. That is the correct outcome.
Where this applies
Frontend advice ages badly and fragments across engines. These labels say what each claim is specific to, and where a different browser, device or framework would differ.
- GENERALThe division of responsibility follows from where code executes and who can be trusted, which does not vary by stack.
- PLATFORM-SPECIFICIn a native or hybrid application the same boundaries exist with different enforcement: there is no origin model, storage guarantees differ, and update is a store release rather than a reload — which makes version skew a much longer-lived problem (Long-Lived Clients and Version Skew).
Where the depth lives
This domain teaches the browser-side mechanism and hands the rest off.
Securityxss
Performancemeasure-before-optimizing
Domains that do not exist yet
- — Testing & Reliability Engineering — which layer can prove which property, and why an end-to-end test is not a substitute for a component contract.
- — Software Design — module boundaries and dependency direction inside the client application itself.