Frontend Developer

Back when the web was closer to a stack of documents, this job didn't exist separately. The server assembled a whole page and shipped it down, the browser laid it out as received, and clicking anything blanked the screen and drew a new one. So whoever built the server built the pages too, and page work was what you did with the time left over.

That arrangement broke down as more code started running inside the browser. Lists fill in without a refresh, a save button changes its own label where it stands, and several things happen at once inside a single screen. Add screen widths running from a phone to a large monitor, plus browsers that each behave a little differently, and page work became enough to fill a day on its own.

Around then the same scene repeated on team after team. The server developer finished their own work and then sat up all night with a layout that only broke in one browser and a button that saved twice when double-clicked. Server work and screen work build the same product, but the problems they run into every day are different in kind, and that's what split the role. The person who took the screen side is the frontend developer.

Most of the day goes into turning one design mockup into a screen that actually runs in a browser. That work splits five ways.

1. Cutting the mockup into pieces. A button, an input, one row of a list — any unit that can be reused is a component, and a screen is built by stacking them. If the team keeps its colors, spacing, and parts under one standard as a design system, the pieces are taken from there rather than built again.
2. Connecting the data. What fills the screen lives on the server and arrives through an API, the agreed channel programs use to exchange things with each other.
3. Building every state. One screen looks different while it's loading, when there's nothing to show, when the request failed, and when the viewer lacks permission — those variants are the UI states. A mockup usually contains one of them, the version where everything went well, so finding and filling the rest takes close to half the working time.
4. Making it hold up across environments. The layout can't collapse on a 360-pixel-wide phone, every button has to be reachable with a keyboard alone, and the code has to tell screen readers what to announce. Most of this is invisible when it works and obvious the moment it doesn't — a dialog that traps the keyboard inside itself looks fine until someone tries to close it without a mouse.
5. Keeping it fast. The work of managing how long a screen takes to appear is web performance. When a first screen slides from one second to three, noticeably more people leave in between, so even adding one image comes with a question about how many milliseconds it costs.

Finished work doesn't go straight in. A colleague reads the change and comments on it first — that step is code review, and it's where a missed state or a performance regression usually gets caught.

Both sides of this job are other disciplines, so the day runs in three directions.

Upstream is design. Mockups come from the product designer, who owns product design from framing the problem through to the screen, and the questions go back the other way: what happens when the list runs past a hundred rows, what moves when a title wraps to two lines. Postponing that conversation means deciding alone mid-build, and different screens end up following different rules.

Downstream is the server. The backend developer, who handles the data and the rules behind the screen, agrees on the shape of what will be exchanged. With the shape settled, the screen can be built against fake data before the server exists, so neither person waits on the other.

To the side are product and quality. Conversations with the product manager, who decides what gets built and why, are mostly about scope — including saying early what won't fit this week. The QA engineer checks the same screen across devices and browsers, which is where problems that never appear on the developer's own machine turn up. A date picker that behaves on a desktop browser can open behind the on-screen keyboard on an older phone, and nobody sees that until someone holds the phone.

"What should this show when the list is empty? There's no empty state in the mockup."

Asking the designer to fill in a case the mockup didn't cover.

"Just settle the response shape and I'll build the screen against fake data."

Meaning the screen won't wait for the server to be finished.

"This animation adds 0.4 seconds to the first paint."

A request for a decision between how it looks and how fast it arrives.

During the week Pagedeck rebuilt its document list screen, Theo had three questions for Noa. What does a new account with no documents see, does a long title get truncated or wrap to a second line, and during loading does the screen stay blank or show a gray skeleton.

None of the three were in the mockup. Noa drew them on the spot, and Theo built four versions of the screen that week: the one where everything goes well, plus the other three. That was also the week Mia moved the screen's estimate from one day to three.

The most common mistake is seeing a frontend developer as the person who makes things look nice. The output is visible, so that's the reading. But deciding what looks good belongs to design, and this job is about turning a settled screen into code that behaves correctly under many conditions. Miss the difference and estimates go wrong. Adding one button sounds like 30 minutes, and then the pressed state, the failure state, and the no-permission state all have to exist and the phone layout has to be checked, and it's two days.

A companion mistake is treating it as the easier side of engineering. Refresh the browser and the result is right there, which makes it look simple. What's actually hard is that the input can't be predicted. A server receives requests in a fixed format, while a screen deals with someone clicking twice, hitting save with the connection dropped, and using the back button to return to the previous screen. Take that lightly and staffing and schedules tilt one way, producing a product where every feature exists and something is off the moment anyone uses it.