Frontend

The web did not start out with a separate discipline for screens. In the early years a server assembled a finished document and sent the whole thing down, and the browser's job ended at displaying what it received. Click something and the signal went back to the server, which produced another finished document to replace the first. For pages meant to be read, that arrangement was a good fit — there was nothing to keep track of between one page and the next.

What broke it was the web turning from something people read into something people operate. Every click meant fetching an entire page again. In an early version of Pagedeck, each time Noa added a comment to a document the screen flashed white, redrew from scratch, and landed at the top of the document rather than where she had been reading. Five comments meant five jumps. When the complaints came in, the team did not stall because the fix was hard. It stalled because the code responsible sat inside the same file that printed the document on the server. The problem happened on a screen, and there was no screen-shaped place to go and fix it.

The split that followed divides work by where the code runs. Everything on the company's own machines — storing and retrieving data, applying the rules of the business — is the backend. Everything running on the device in the user's hand is the frontend. Once that line is drawn, even a single save button obviously involves both halves. Whether the button turns grey the instant it is clicked, with a small spinner beside it, belongs to the near side. Whether the text is genuinely stored, so it opens tomorrow on a different laptop, belongs to the far side.

The two halves meet at an API (application programming interface), an agreement settled in advance about what the two programs send each other and in what shape. The screen only has to honor the agreement; what happens inside the server is none of its business. And because the agreement can be written down before either half is built, a screen can be finished while the server behind it is still empty: fill in fake values in the agreed shape, build the whole interface against them, and swap in the real address when the server is ready.

What made the near side big enough to deserve its own field is that the stage belongs to someone else. A server runs on machines the company chose, under conditions the company set. A screen runs on whatever device the user happens to own, in whatever browser they happen to open. The same interface has to work on a three-year-old Android phone, on a connection that drops in a subway tunnel, and for someone who has set their text size to 150 percent. None of those conditions go away no matter how much work goes into the server.

The terms filed under frontend follow the path a line of code takes to become a pixel on a screen. What the screen is written in is foundations. When and where it gets drawn is rendering. How a large interface gets divided up is composition. How the pieces get packaged for delivery is build. Two smaller branches sit alongside: form, which covers making a web page behave like an installed app, and compatibility, which covers making browsers that disagree behave the same. Six branches in all.

Foundations are the languages a screen is written in. There are five, and their roles do not overlap.

1. HTML (hypertext markup language) — the markup language that states what is on a screen. This is a heading, this is a paragraph, this is a button you can press. It is not a language for deciding how things look; it is a language for declaring what things are.
2. CSS (cascading style sheets) — the style language that decides how those things appear. Text size, spacing, and color, of course, but also the rules that restack a row of items into a column when the window narrows.
3. JavaScript — the language that produces behavior in the browser. It opens something when a button is pressed, checks on the spot whether a typed value fits the rules, and sends a request to the server and swaps in whatever comes back.
4. TypeScript — JavaScript plus a syntax for writing down, in advance, what kind of value belongs where. Put text where a number was expected and it gets caught before anything runs. The value of catching things early grows with the number of people and screens involved, so past a certain size teams treat it as the default.
5. DOM (document object model) — the loaded document turned into a tree of objects that code can reach into. When JavaScript "changes the screen," what it actually changes is this tree.

Rendering decides when and where a screen gets drawn. A single-page application (SPA) loads one document and swaps out the contents from then on. Nothing is fetched wholesale on each move, so the flicker from the scene above disappears. Client-side rendering hands all the drawing to the browser, which leaves a long empty stretch before the first screen appears; server-side rendering draws it on the server first so something shows up fast. Static site generation goes further and builds every page before deployment, and incremental static regeneration rebuilds only the pages whose content actually changed. Hydration is the step that attaches behavior to a server-drawn screen after the fact, and it opens a gap of a few hundred milliseconds where the screen is visible but nothing responds to a tap.

Composition is about dividing an interface that has grown. A component is a reusable unit of screen code that bundles one fragment — a button, a single comment row — together with its structure, its styling, and its behavior. The same button can appear on ten screens while its definition lives in one place. State management is about deciding where the values a screen has to remember are kept and who may change them: who is signed in, which document is open, whether a save is in flight. When one of those values changes, every screen that reads it has to change too. Props drilling is the problem of passing such a value down by hand, one level at a time. To hand a value to something seven levels down, the six components in between have to accept and forward a value none of them uses.

Build is about packaging the pieces for delivery. A bundler takes hundreds of separate files and combines them into the handful a browser can fetch efficiently. The other three terms are ways of making that package smaller. Tree shaking strips out code that was imported but never actually used. Code splitting stops handing over everything up front and instead delivers each screen's share when someone opens that screen. Lazy loading defers resources that are not visible yet, like images further down the page. Without all three, someone who never once opens the settings screen still downloads the settings screen on first load.

Form and compatibility are about fitting the result to real conditions. A progressive web app is a web product packaged so it can be installed on a home screen and send notifications, which is what teams reach for when they want something app-like without going through an app store. Cross-browser compatibility is the work of getting the same screen to behave the same in Chrome, Safari, and Firefox, and a polyfill helps with that by supplying a stand-in for a capability an older browser lacks.

The six branches pull on each other rather than running in sequence. Splitting an interface into small pieces multiplies the files, which is what creates the need for packaging; a package that grows delays the first screen, which is what sends teams to server-side rendering and code splitting; and choosing server-side rendering introduces hydration as a fresh problem of its own.

"We can catch that on the frontend. No round trip to the server — just tell them right there on the screen."

Anything knowable without asking the server, like a blank field or a malformed entry, should be answered where the person is standing.

"We'll wire up the frontend first this week. The data is still fake, so just look at the screens."

The interface is being finished against placeholder values in the agreed shape, with the real server connected later — and a warning not to read any of the numbers on display as real.

"This screen is heavy on the frontend. Three megabytes on first load, which is eight seconds on a phone outside."

The complaint is not about missing features but about the sheer volume of code and images being fetched, and it is a signal that the build side needs attention.

At Pagedeck this is where Theo and Noa work against each other's output. Noa hands over a screen and Theo turns it into code, and the handoff always leaves the same set of questions open. What happens when a title runs long enough to wrap to two lines. What shows when the list is empty. What appears while things are still loading. A drawing shows one case, the one where everything went well, but code has to decide every other case too. So the two of them now settle three states together whenever a screen changes hands: empty, loading, and failed.

What Mia asks about most often is when something can be shown. Screens run on fake values even in a week when server work has slipped, so user tests and investor demos get scheduled against the near side alone. The catch is that such a screen proves nothing about whether anything is actually saved, and features that looked fine in a demo sometimes come apart the week the real connection lands.

The most common mistake is treating frontend work as transcribing a design. The output is a visible screen and a designer decides its shape first, so the reading is understandable. But everything missing from the drawing still has to exist in the code. What shows when the list is empty, when loading fails, when the viewer lacks permission, when two people edit the same document at once — every one of those has to be decided, and there are far more of them than there are good-case screens. Teams holding this belief miss estimates the same way every time: ten drawings get scoped as ten days and take three weeks, and the extra time went into deciding and building the screens nobody drew.

The second mistake is assuming that because screens are visible, their problems are obvious. It sounds fair next to the backend, where a failure only shows up if someone reads the logs. But it is only true on the machine you happen to be using. The same code misaligns a button in Safari and nowhere else, stutters when scrolled on a cheap Android handset and nowhere else, clips text only for the person who enlarged their font. The people building it are usually on a recent laptop, in Chrome, on office wifi, and experience none of that. Left in place, this belief means reports get dismissed as unreproducible, and the real cost surfaces months later as a quiet drop in users on one browser.