Think of searching for a flight on a travel website. A person types two cities and a date, and a list of flights appears. Filters for price, airline and time narrow it down as they are clicked, without the page reloading. On a phone the same page rearranges itself into one neat column.
Each of those pieces is a component, a small reusable piece of the screen, and a frontend engineer wrote it, usually in React with TypeScript, the version of JavaScript that catches mistakes before the code runs. Angular and Vue do the same job. The engineer decided what the page should remember as the person clicks, such as which filters are on, and kept every part of the screen in step with it. They called the backend's APIs to fetch the flights, and showed a clear message when something failed. They made sure the page works with a keyboard and a screen reader, and loads fast on a slow connection.
The work involves building and changing the screens of a web application. On the travel website that could mean a new filter for flights with free baggage, built from a designer's mock-up, a fresh page for choosing seats, or a change to the checkout form so that it asks for fewer details. It also means finding out why something looks or behaves wrong, such as a price on the screen that does not match the price charged, or a results page that takes too long to appear, and fixing it. When a page looks wrong on one browser or one phone, the frontend engineer is the one who finds out why. Before any of this is built, the engineer agrees the details with designers, product managers and the backend engineers whose APIs the screen will call.
Writing the screen is only part of the job. Around it sits a set of duties that every frontend engineer shares.
Every change is read by a teammate in a code review before it is accepted, and every engineer reviews the changes of others in turn. Each change carries automated tests, small ones in Jest that check a single component and larger ones in Cypress or Playwright that click through a page the way a person would. A CI/CD pipeline runs those tests whenever code is pushed and, once they pass, delivers the new version of the site to the live servers. Frontend engineers keep their part of that pipeline working.
They also look after how the site performs once it is live. The code is bundled and shrunk so that pages load fast, served from a content delivery network that keeps copies close to the people using it, and watched with tools that report errors from real browsers and show how quickly pages appear. Accessibility is part of the job too, so the screens work with a keyboard alone and with the screen readers that blind people use.
Planning is part of the job as well. Work is usually split into short cycles called sprints, tracked as tickets in a tool such as Jira. Engineers estimate how long a task will take, give a short update at a daily stand-up meeting, and with experience break a large screen into smaller pieces that a team can share.
A
The ideal candidate has a keen eye for design and a feel for how people actually use a screen, where the eye goes first, which steps make a form tiring, and what makes a page easy to find one's way around. Such a person cares how things look and feel, notices when a button sits slightly out of place, and enjoys seeing the work the moment it is saved. With experience, frontend engineers decide how a large web application is organised and set the shared components other teams build with. Some become full-stack by learning the server side, often in Node.js. Others move into mobile through React Native, which uses the same ideas.