跪拜 Guibai
← All articles
Frontend · JavaScript · Programmer

Frontend's 90% Invisible Complexity

By ErpanOmer ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Backend engineers who dismiss frontend as "just drawing buttons" misunderstand the engineering surface. Frontend is the only layer that runs on hardware you don't control, under network conditions you can't predict, while managing state that lives for an entire user session — a combination that creates failure modes no server-side code ever encounters.

Summary

The illusion that frontend is easy comes from its instant visual feedback: a few lines of HTML produce a colorful card, and component libraries make admin panels trivial to assemble. That speed masks where the real work lives. Rendering a page is the first 10%. The other 90% is defending against an environment no backend engineer has to tolerate — shattered screens, 2 GB of memory, ad blockers injecting rogue scripts, and networks that oscillate between 4G and dead zones.

On top of that hostile runtime, frontend state persists for minutes or hours, not the milliseconds of a stateless API call. A user hammering a submit button ten times in a weak network creates an asynchronous race-condition disaster that demands request deduplication, abort controllers, and careful memory cleanup. Every long-lived page tab is a state machine that must survive chaotic human input without leaking memory or corrupting data.

The frameworks and the senior engineers who build the invisible safety nets make it look simple. But the job is to bridge machine code and unpredictable human behavior under the worst physical conditions a device can throw at you.

Takeaways
Rendering a UI is roughly 10% of modern frontend work; the remaining 90% is handling failure, state, and hostile runtime conditions.
Backend code runs on controlled, homogeneous infrastructure; frontend code runs on shattered screens, 2 GB phones, and networks that drop mid-request.
Ad blockers, translation plugins, and browser extensions can inject code that mutates the DOM in ways the original developer never anticipated.
Frontend state persists for minutes or hours inside an SPA, unlike a stateless backend request that lives for milliseconds.
A user rapidly clicking a submit button in weak network conditions creates an asynchronous race condition that requires abort controllers, request deduplication, and manual memory cleanup to prevent corruption and leaks.
Long-lived page tabs demand precise cleanup of Maps, event listeners, and pending requests to avoid memory overflow over time.
Conclusions

The perception gap between frontend and backend complexity is largely a visibility problem: backend failure is a log line or a 500 error, while frontend failure is a blank screen or a double charge — but the defensive code that prevents it is invisible.

Frontend's unique engineering challenge is that it must reconcile two chaotic systems simultaneously: the physical world of devices and networks, and the psychological world of impatient, error-prone human users.

The industry's bootcamp marketing and component-library ecosystem actively reinforce the myth that frontend is easy, because they optimize for the 10% demo path and never expose the 90% defensive layer.

Concepts & terms
Asynchronous race condition
A bug where multiple concurrent operations complete in an unpredictable order, causing stale or duplicate data. In frontend, a user rapidly clicking a button can fire several network requests; without abort logic, the last click might be overwritten by an earlier, slower response.
AbortController
A browser API that lets JavaScript cancel an in-flight fetch request by calling .abort() on its signal. Frontend engineers use it to kill duplicate requests and prevent race conditions when users trigger rapid, repeated actions.
SPA (Single Page Application)
A web app that loads a single HTML page and dynamically rewrites content as the user interacts, rather than loading entire new pages from the server. This architecture keeps state alive for the full session, making state management and memory cleanup far more critical than in multi-page apps.
From the discussion

The pushback against the article's premise centers on backend complexity and business impact. The counterargument holds that backend failures are fatal, while frontend failures are survivable, and that backend state management is more intricate. A pragmatic view ties complexity to user scale and profitability, dismissing internal tools as trivial. The harshest takes dismiss critics of frontend complexity as incompetent or invite them to inspect real-world codebases.

Frontend environment complexity is bounded by mainstream hosts and rarely causes fatal business failures, unlike backend instability where full thread pools bring services down.
Backend state machines are more complex than frontend ones, involving state jumps and reconciliation logic.
Perceived frontend simplicity stems from its lower business impact—rough code still runs—and from a lack of career reward for polishing UI details.
Complexity scales with user count and revenue; internal CRUD systems are so simple they barely need a dedicated frontend.
Entry into frontend development is easy, but mastery is not.
Critics who dismiss frontend complexity should examine production codebases like Claude Code's source.
Some dismiss the entire debate by labeling detractors as arrogant and incompetent.
Featured comments
yeyan1996 3 likes

I don't quite agree. From an environmental perspective, although the frontend host environment is complex, you usually only need to support mainstream host environments, and the impact on the business is not fatal. The backend host environment is stable, but upstream and downstream dependencies are unstable. You need to consider rate limiting, circuit breaking, and flow control. Once the thread pool is full, the service becomes directly unavailable, which is fatal to the business. From a state perspective: the backend generally has more state than the frontend, and the state machine is more complex than the frontend, for example, needing to handle state jumps and reconciliation. Many people think the frontend is simple, but the underlying belief is that the frontend's impact on the business is small, and it can still run even if the code is a bit rough. Looking at it another way, even if the frontend is really complex, most companies won't give you a promotion or a raise just because a frontend engineer wrote a silky-smooth interactive animation or solved a button's rapid-click problem.

王嗨皮

Whether it's simple or not depends on how many users there are and whether it's profitable. If it's profitable or has many users, it's quite not simple. If it's just an internal enterprise CRUD management system, then... you don't even need a frontend [facepalm]

ErpanOmer

Yes

drizzle

The simplest example: people who say the frontend is simple can go look at the source code of claudecode [polite smile]

ErpanOmer

Good idea 👍

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗