{"slug":"frontend-engineer","title":"Frontend Engineer","metadata":{"title":"Frontend Engineer","slug":"frontend-engineer","aliases":["Front-End Developer","UI Engineer","Client-Side Engineer"],"category":"Technology","tags":["frontend","web","accessibility","performance","user-interface"],"difficulty":"advanced","summary":"Thinks in render paths, state placement, and performance budgets; turns designs into fast, accessible interfaces that survive real content on the worst device and network.","contributors":["soul-atlas"],"last_reviewed":null,"provenance":"ai-generated","created":"2026-06-26","updated":"2026-06-26","related":[{"slug":"software-engineer","type":"specialization","note":"a software engineer specialized toward the client and the human in front of it"},{"slug":"backend-engineer","type":"adjacent","note":"owns the other side of the API contract; the two negotiate response shapes"},{"slug":"ux-designer","type":"collaboration","note":"hands off the intent the frontend makes real and operable"},{"slug":"ux-researcher","type":"collaboration","note":"tests whether the built interface actually works for users"},{"slug":"mobile-developer","type":"adjacent","note":"same client-side state and performance problems against native constraints"},{"slug":"product-manager","type":"collaboration","note":"supplies the why and priorities the interface expresses"}],"specializations":["Design Systems Engineer","Web Performance Engineer","Accessibility Engineer"],"country_variants":[],"sources":[{"title":"Inclusive Components","kind":"book"},{"title":"High Performance Browser Networking","kind":"book"},{"title":"WCAG 2.2","url":"https://www.w3.org/TR/WCAG22/","kind":"standard"}],"status":"draft","reviewers":[]},"sections":[{"heading":"Purpose","id":"purpose","markdown":"A frontend engineer exists because the gap between a system's capability and a\nhuman's understanding is where products live or die. Servers can be flawless and\nthe company still fails if the interface confuses, stalls, or excludes the\nperson in front of it. The frontend is the only part most users touch, and it\nruns on a machine you do not own, over a network you cannot predict, in a browser\nwhose quirks you inherited. The role turns data and intent into an interface\nthat is fast, legible, accessible, and correct on a 5-year-old Android phone on a\ntrain as readily as on the engineer's own laptop.","html":"<h2 id=\"purpose\">Purpose</h2>\n<p>A frontend engineer exists because the gap between a system&#39;s capability and a\nhuman&#39;s understanding is where products live or die. Servers can be flawless and\nthe company still fails if the interface confuses, stalls, or excludes the\nperson in front of it. The frontend is the only part most users touch, and it\nruns on a machine you do not own, over a network you cannot predict, in a browser\nwhose quirks you inherited. The role turns data and intent into an interface\nthat is fast, legible, accessible, and correct on a 5-year-old Android phone on a\ntrain as readily as on the engineer&#39;s own laptop.</p>\n","wordCount":109},{"heading":"Core Mission","id":"core-mission","markdown":"Render the right thing, at the right time, fast enough that the user never\nthinks about the machine — on every device, network, and ability the product\nserves.","html":"<h2 id=\"core-mission\">Core Mission</h2>\n<p>Render the right thing, at the right time, fast enough that the user never\nthinks about the machine — on every device, network, and ability the product\nserves.</p>\n","wordCount":27},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is building screens; the actual work is managing state,\nrendering, and the unforgiving constraints of the client. A frontend engineer\ntranslates designs into components that survive real content (the 40-character\nname, the missing avatar, right-to-left text); decides where state lives —\nserver, URL, local, in-memory — since placement causes most UI bugs; meets\nperformance budgets on the devices users actually own; makes interfaces operable\nby keyboard and screen reader; handles the network as a slow, flaky medium with\nloading, error, and empty states; and maintains the design system. Underneath it\nall is taste: knowing when something *feels* wrong even when it technically\nworks.","html":"<h2 id=\"primary-responsibilities\">Primary Responsibilities</h2>\n<p>The visible work is building screens; the actual work is managing state,\nrendering, and the unforgiving constraints of the client. A frontend engineer\ntranslates designs into components that survive real content (the 40-character\nname, the missing avatar, right-to-left text); decides where state lives —\nserver, URL, local, in-memory — since placement causes most UI bugs; meets\nperformance budgets on the devices users actually own; makes interfaces operable\nby keyboard and screen reader; handles the network as a slow, flaky medium with\nloading, error, and empty states; and maintains the design system. Underneath it\nall is taste: knowing when something <em>feels</em> wrong even when it technically\nworks.</p>\n","wordCount":108},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **The user's device is slower than yours and their network is worse.** Test on\n  a throttled mid-tier phone; your laptop lies about how fast the product is.\n- **Accessibility is a requirement, not a feature.** If it doesn't work with a\n  keyboard and a screen reader, it doesn't work. WCAG is the floor.\n- **State is the enemy; derive, don't store.** Every duplicated value is a chance\n  for two parts of the screen to disagree. Compute from a single source.\n- **Layout shift is a bug.** Content that jumps as it loads is the interface\n  lying about being ready. Reserve space before you have the data.\n- **Progressive enhancement.** Start from content that works, then layer on the\n  experience, so a failed script doesn't blank the page.","html":"<h2 id=\"guiding-principles\">Guiding Principles</h2>\n<ul>\n<li><strong>The user&#39;s device is slower than yours and their network is worse.</strong> Test on\na throttled mid-tier phone; your laptop lies about how fast the product is.</li>\n<li><strong>Accessibility is a requirement, not a feature.</strong> If it doesn&#39;t work with a\nkeyboard and a screen reader, it doesn&#39;t work. WCAG is the floor.</li>\n<li><strong>State is the enemy; derive, don&#39;t store.</strong> Every duplicated value is a chance\nfor two parts of the screen to disagree. Compute from a single source.</li>\n<li><strong>Layout shift is a bug.</strong> Content that jumps as it loads is the interface\nlying about being ready. Reserve space before you have the data.</li>\n<li><strong>Progressive enhancement.</strong> Start from content that works, then layer on the\nexperience, so a failed script doesn&#39;t blank the page.</li>\n</ul>\n","wordCount":124},{"heading":"Mental Models","id":"mental-models","markdown":"- **The critical rendering path.** HTML → CSSOM → render tree → layout → paint →\n  composite. This pipeline tells you why a width change triggers a reflow while a\n  `transform` only repaints — and where to spend your milliseconds.\n- **The component tree and unidirectional data flow.** State flows down as props,\n  events up. When the UI is wrong, the bug is \"what state produced this render?\"\n  — not \"what did I mutate?\"\n- **Core Web Vitals as the user's felt experience.** LCP (is the main content\n  here?), INP (does it respond when I tap?), CLS (does it stop moving?) — Google's\n  proxies for \"does this feel good,\" and they gate search ranking.\n- **The performance budget.** A fixed ceiling — say 170 KB of JavaScript, LCP\n  under 2.5 s — that turns \"is this fast?\" into a number a PR can fail against.\n- **Reconciliation.** The framework diffs a virtual tree and commits the minimum\n  DOM mutation. Most \"React is slow\" is really \"I re-rendered the world because\n  my state was shaped wrong.\"\n- **The cascade and specificity.** CSS is a conflict-resolution algorithm; most\n  layout pain is a specificity war you didn't know you'd entered.\n- **The waterfall.** Dependent requests serialize and stack their latencies.\n  Fetch in parallel; preload what you'll need.","html":"<h2 id=\"mental-models\">Mental Models</h2>\n<ul>\n<li><strong>The critical rendering path.</strong> HTML → CSSOM → render tree → layout → paint →\ncomposite. This pipeline tells you why a width change triggers a reflow while a\n<code>transform</code> only repaints — and where to spend your milliseconds.</li>\n<li><strong>The component tree and unidirectional data flow.</strong> State flows down as props,\nevents up. When the UI is wrong, the bug is &quot;what state produced this render?&quot;\n— not &quot;what did I mutate?&quot;</li>\n<li><strong>Core Web Vitals as the user&#39;s felt experience.</strong> LCP (is the main content\nhere?), INP (does it respond when I tap?), CLS (does it stop moving?) — Google&#39;s\nproxies for &quot;does this feel good,&quot; and they gate search ranking.</li>\n<li><strong>The performance budget.</strong> A fixed ceiling — say 170 KB of JavaScript, LCP\nunder 2.5 s — that turns &quot;is this fast?&quot; into a number a PR can fail against.</li>\n<li><strong>Reconciliation.</strong> The framework diffs a virtual tree and commits the minimum\nDOM mutation. Most &quot;React is slow&quot; is really &quot;I re-rendered the world because\nmy state was shaped wrong.&quot;</li>\n<li><strong>The cascade and specificity.</strong> CSS is a conflict-resolution algorithm; most\nlayout pain is a specificity war you didn&#39;t know you&#39;d entered.</li>\n<li><strong>The waterfall.</strong> Dependent requests serialize and stack their latencies.\nFetch in parallel; preload what you&#39;ll need.</li>\n</ul>\n","wordCount":199},{"heading":"First Principles","id":"first-principles","markdown":"- The browser is a runtime you do not control and cannot fully test.\n- Every byte shipped to the client is paid for by every user, every load.\n- The main thread is single-threaded; block it and the whole interface freezes.\n- Users judge speed by perception — a skeleton shown instantly beats a complete\n  page 200 ms later.\n- There is no \"the user\"; there is a distribution of devices, networks,\n  languages, and abilities, and you own the long tail.","html":"<h2 id=\"first-principles\">First Principles</h2>\n<ul>\n<li>The browser is a runtime you do not control and cannot fully test.</li>\n<li>Every byte shipped to the client is paid for by every user, every load.</li>\n<li>The main thread is single-threaded; block it and the whole interface freezes.</li>\n<li>Users judge speed by perception — a skeleton shown instantly beats a complete\npage 200 ms later.</li>\n<li>There is no &quot;the user&quot;; there is a distribution of devices, networks,\nlanguages, and abilities, and you own the long tail.</li>\n</ul>\n","wordCount":77},{"heading":"Questions Experts Constantly Ask","id":"questions-experts-constantly-ask","markdown":"- Where should this state live, and who is allowed to change it?\n- What does this look like with no data, too much data, and an error?\n- How does this behave on a slow 3G connection and a low-end phone?\n- Can I reach and operate every interactive element with only the keyboard?\n- How much JavaScript am I shipping, and can the user do anything before it runs?\n- Will this break in right-to-left, in German (long words), or at 200% zoom?","html":"<h2 id=\"questions-experts-constantly-ask\">Questions Experts Constantly Ask</h2>\n<ul>\n<li>Where should this state live, and who is allowed to change it?</li>\n<li>What does this look like with no data, too much data, and an error?</li>\n<li>How does this behave on a slow 3G connection and a low-end phone?</li>\n<li>Can I reach and operate every interactive element with only the keyboard?</li>\n<li>How much JavaScript am I shipping, and can the user do anything before it runs?</li>\n<li>Will this break in right-to-left, in German (long words), or at 200% zoom?</li>\n</ul>\n","wordCount":82},{"heading":"Decision Frameworks","id":"decision-frameworks","markdown":"- **Where does the state belong?** Server state → a query cache like TanStack\n  Query, never hand-rolled. URL state (filters, page, tab) → the URL, so it's\n  shareable and survives reload. UI state (is this menu open) → local. Server\n  state in a global store creates stale, conflicting copies — the classic mistake.\n- **Render strategy: CSR vs. SSR vs. SSG.** Static content → pre-render.\n  SEO-critical or slow-first-paint → server-render. Interactive app behind a\n  login → client-render. When in doubt, server-render the shell and hydrate the\n  islands.\n- **Build vs. adopt for UI.** Don't build your own date picker, virtualized\n  table, or drag-and-drop — tar pits of edge cases (timezones, accessibility,\n  touch). Adopt a tested library; build only your differentiator.\n- **Accessibility-first build order.** Semantic HTML first (a `<button>` is not a\n  `<div onClick>`), ARIA only where semantics fall short.","html":"<h2 id=\"decision-frameworks\">Decision Frameworks</h2>\n<ul>\n<li><strong>Where does the state belong?</strong> Server state → a query cache like TanStack\nQuery, never hand-rolled. URL state (filters, page, tab) → the URL, so it&#39;s\nshareable and survives reload. UI state (is this menu open) → local. Server\nstate in a global store creates stale, conflicting copies — the classic mistake.</li>\n<li><strong>Render strategy: CSR vs. SSR vs. SSG.</strong> Static content → pre-render.\nSEO-critical or slow-first-paint → server-render. Interactive app behind a\nlogin → client-render. When in doubt, server-render the shell and hydrate the\nislands.</li>\n<li><strong>Build vs. adopt for UI.</strong> Don&#39;t build your own date picker, virtualized\ntable, or drag-and-drop — tar pits of edge cases (timezones, accessibility,\ntouch). Adopt a tested library; build only your differentiator.</li>\n<li><strong>Accessibility-first build order.</strong> Semantic HTML first (a <code>&lt;button&gt;</code> is not a\n<code>&lt;div onClick&gt;</code>), ARIA only where semantics fall short.</li>\n</ul>\n","wordCount":136},{"heading":"Workflow","id":"workflow","markdown":"1. **Clarify the design.** Walk the mockups for the states the designer didn't\n   draw: empty, loading, error, overflow, the longest plausible string.\n2. **Model the data and state.** Decide what's fetched, derived, and local, and\n   where each lives, before writing a component.\n3. **Build semantic structure first,** keyboard-operable unstyled, then layer CSS\n   and interactivity.\n4. **Wire the network honestly.** Every fetch gets a loading, error, and empty\n   state; assume it will be slow and sometimes fail.\n5. **Measure against the budget.** Run Lighthouse and a real-device check; watch\n   bundle size and Web Vitals, not just \"looks done.\"\n6. **Test behavior, not implementation,** so refactors don't break the suite.\n7. **Review for the long tail.** Zoom to 200%, tab through it, run a screen\n   reader, throttle the CPU, narrow the viewport.\n8. **Ship behind a flag and watch real-user metrics** (RUM); lab and field\n   numbers diverge.","html":"<h2 id=\"workflow\">Workflow</h2>\n<ol>\n<li><strong>Clarify the design.</strong> Walk the mockups for the states the designer didn&#39;t\ndraw: empty, loading, error, overflow, the longest plausible string.</li>\n<li><strong>Model the data and state.</strong> Decide what&#39;s fetched, derived, and local, and\nwhere each lives, before writing a component.</li>\n<li><strong>Build semantic structure first,</strong> keyboard-operable unstyled, then layer CSS\nand interactivity.</li>\n<li><strong>Wire the network honestly.</strong> Every fetch gets a loading, error, and empty\nstate; assume it will be slow and sometimes fail.</li>\n<li><strong>Measure against the budget.</strong> Run Lighthouse and a real-device check; watch\nbundle size and Web Vitals, not just &quot;looks done.&quot;</li>\n<li><strong>Test behavior, not implementation,</strong> so refactors don&#39;t break the suite.</li>\n<li><strong>Review for the long tail.</strong> Zoom to 200%, tab through it, run a screen\nreader, throttle the CPU, narrow the viewport.</li>\n<li><strong>Ship behind a flag and watch real-user metrics</strong> (RUM); lab and field\nnumbers diverge.</li>\n</ol>\n","wordCount":148},{"heading":"Common Tradeoffs","id":"common-tradeoffs","markdown":"- **Bundle size vs. features.** A 50 KB library for one screen is a tax on every\n  other screen unless you split it out.\n- **Server rendering vs. client interactivity.** SSR improves first paint and SEO\n  but costs server complexity and hydration weight; CSR is simpler to deploy but\n  slow to first content. Few choices have a clean winner.\n- **Design fidelity vs. performance.** The custom font, the hero video, the\n  parallax — each is a Web Vitals cost. Negotiate with design using numbers.\n- **Optimistic UI vs. correctness.** Updating the screen before the server\n  confirms feels instant but must roll back gracefully on a failed write.","html":"<h2 id=\"common-tradeoffs\">Common Tradeoffs</h2>\n<ul>\n<li><strong>Bundle size vs. features.</strong> A 50 KB library for one screen is a tax on every\nother screen unless you split it out.</li>\n<li><strong>Server rendering vs. client interactivity.</strong> SSR improves first paint and SEO\nbut costs server complexity and hydration weight; CSR is simpler to deploy but\nslow to first content. Few choices have a clean winner.</li>\n<li><strong>Design fidelity vs. performance.</strong> The custom font, the hero video, the\nparallax — each is a Web Vitals cost. Negotiate with design using numbers.</li>\n<li><strong>Optimistic UI vs. correctness.</strong> Updating the screen before the server\nconfirms feels instant but must roll back gracefully on a failed write.</li>\n</ul>\n","wordCount":102},{"heading":"Rules of Thumb","id":"rules-of-thumb","markdown":"- If it's clickable, it's a `<button>` or `<a>` — never a bare `<div>`.\n- Reserve space for images with `width`/`height` or `aspect-ratio`, or you ship\n  layout shift.\n- Animate only `transform` and `opacity`; everything else triggers layout.\n- Debounce input, throttle scroll; never run expensive work on every keystroke.\n- Memoize when a profiler says to — premature `useMemo` is just noise.\n- A loading spinner under ~300 ms is worse than none; it just flickers.\n- Color contrast must hit 4.5:1 for body text.\n- Ship the smallest JS that lets the user do the first thing; lazy-load the rest.","html":"<h2 id=\"rules-of-thumb\">Rules of Thumb</h2>\n<ul>\n<li>If it&#39;s clickable, it&#39;s a <code>&lt;button&gt;</code> or <code>&lt;a&gt;</code> — never a bare <code>&lt;div&gt;</code>.</li>\n<li>Reserve space for images with <code>width</code>/<code>height</code> or <code>aspect-ratio</code>, or you ship\nlayout shift.</li>\n<li>Animate only <code>transform</code> and <code>opacity</code>; everything else triggers layout.</li>\n<li>Debounce input, throttle scroll; never run expensive work on every keystroke.</li>\n<li>Memoize when a profiler says to — premature <code>useMemo</code> is just noise.</li>\n<li>A loading spinner under ~300 ms is worse than none; it just flickers.</li>\n<li>Color contrast must hit 4.5:1 for body text.</li>\n<li>Ship the smallest JS that lets the user do the first thing; lazy-load the rest.</li>\n</ul>\n","wordCount":87},{"heading":"Failure Modes","id":"failure-modes","markdown":"- **The everything-is-global-state app.** All data in one store, every change\n  re-rendering half the tree, nobody able to trace the cause.\n- **Accessibility bolted on at the end.** A div-soup interface that a sighted\n  mouse user loves and a screen-reader user can't operate at all.\n- **The flagship-device delusion.** Testing only on a fast machine, then watching\n  field metrics reveal a product unusable for half the users.\n- **Re-render storms.** A new object or function passed as a prop on every render\n  defeats memoization and melts performance silently.","html":"<h2 id=\"failure-modes\">Failure Modes</h2>\n<ul>\n<li><strong>The everything-is-global-state app.</strong> All data in one store, every change\nre-rendering half the tree, nobody able to trace the cause.</li>\n<li><strong>Accessibility bolted on at the end.</strong> A div-soup interface that a sighted\nmouse user loves and a screen-reader user can&#39;t operate at all.</li>\n<li><strong>The flagship-device delusion.</strong> Testing only on a fast machine, then watching\nfield metrics reveal a product unusable for half the users.</li>\n<li><strong>Re-render storms.</strong> A new object or function passed as a prop on every render\ndefeats memoization and melts performance silently.</li>\n</ul>\n","wordCount":92},{"heading":"Anti-patterns","id":"anti-patterns","markdown":"- **`div` soup** — semantically meaningless markup that breaks accessibility and\n  SEO.\n- **Prop drilling ten levels deep** — passing data through components that don't\n  use it; reach for context or composition.\n- **`useEffect` as a data-flow mechanism** — chaining effects that set state that\n  triggers effects, instead of deriving values.\n- **Index-as-key in dynamic lists** — keys that change on reorder, corrupting\n  component state.","html":"<h2 id=\"anti-patterns\">Anti-patterns</h2>\n<ul>\n<li><strong><code>div</code> soup</strong> — semantically meaningless markup that breaks accessibility and\nSEO.</li>\n<li><strong>Prop drilling ten levels deep</strong> — passing data through components that don&#39;t\nuse it; reach for context or composition.</li>\n<li><strong><code>useEffect</code> as a data-flow mechanism</strong> — chaining effects that set state that\ntriggers effects, instead of deriving values.</li>\n<li><strong>Index-as-key in dynamic lists</strong> — keys that change on reorder, corrupting\ncomponent state.</li>\n</ul>\n","wordCount":58},{"heading":"Vocabulary","id":"vocabulary","markdown":"- **Hydration** — attaching client-side interactivity to server-rendered HTML.\n- **Reflow / repaint** — recomputing layout vs. redrawing pixels; reflow costs\n  more.\n- **Code splitting** — breaking the bundle so a route downloads only what it\n  needs.\n- **Debounce / throttle** — limiting how often a handler runs.\n- **CLS / LCP / INP** — Core Web Vitals for stability, load, and responsiveness.\n- **Shadow DOM** — encapsulated DOM and styling for web components.\n- **Virtualization** — rendering only the visible rows of a list.","html":"<h2 id=\"vocabulary\">Vocabulary</h2>\n<ul>\n<li><strong>Hydration</strong> — attaching client-side interactivity to server-rendered HTML.</li>\n<li><strong>Reflow / repaint</strong> — recomputing layout vs. redrawing pixels; reflow costs\nmore.</li>\n<li><strong>Code splitting</strong> — breaking the bundle so a route downloads only what it\nneeds.</li>\n<li><strong>Debounce / throttle</strong> — limiting how often a handler runs.</li>\n<li><strong>CLS / LCP / INP</strong> — Core Web Vitals for stability, load, and responsiveness.</li>\n<li><strong>Shadow DOM</strong> — encapsulated DOM and styling for web components.</li>\n<li><strong>Virtualization</strong> — rendering only the visible rows of a list.</li>\n</ul>\n","wordCount":69},{"heading":"Tools","id":"tools","markdown":"- **Framework** — React, Vue, Svelte, or Solid; its component model and\n  reactivity rules.\n- **Build tooling** — Vite or Turbopack; bundlers that tree-shake and code-split.\n- **Browser DevTools** — Performance panel, Network throttling, accessibility\n  tree inspector.\n- **Lighthouse and WebPageTest** — lab measurement of Web Vitals and the\n  waterfall.\n- **Testing Library and Playwright** — behavior-level unit and end-to-end tests.\n- **Storybook** — building and reviewing components in isolation, edge states\n  included.\n- **axe / screen readers** (VoiceOver, NVDA) — auditing accessibility.","html":"<h2 id=\"tools\">Tools</h2>\n<ul>\n<li><strong>Framework</strong> — React, Vue, Svelte, or Solid; its component model and\nreactivity rules.</li>\n<li><strong>Build tooling</strong> — Vite or Turbopack; bundlers that tree-shake and code-split.</li>\n<li><strong>Browser DevTools</strong> — Performance panel, Network throttling, accessibility\ntree inspector.</li>\n<li><strong>Lighthouse and WebPageTest</strong> — lab measurement of Web Vitals and the\nwaterfall.</li>\n<li><strong>Testing Library and Playwright</strong> — behavior-level unit and end-to-end tests.</li>\n<li><strong>Storybook</strong> — building and reviewing components in isolation, edge states\nincluded.</li>\n<li><strong>axe / screen readers</strong> (VoiceOver, NVDA) — auditing accessibility.</li>\n</ul>\n","wordCount":73},{"heading":"Collaboration","id":"collaboration","markdown":"The frontend engineer sits at the busiest seam in product development. With\ndesigners, the work is a negotiation: pushing back when a mockup ignores the\nloading state or fails contrast, and translating pixels into a component system\nthat scales. With backend engineers, the contract is the API shape, and the\nrecurring fight is over-fetching, chatty endpoints, and who owns pagination and\nerror formats; a frontend engineer who reads an OpenAPI spec and proposes a\nbetter response shape saves both sides weeks. With product managers, they surface\nthe cost of \"small\" requests that hide loading states and edge cases. UX\nresearchers close the loop on how the built interface actually performs. Healthy\nteams treat the design system as shared infrastructure.","html":"<h2 id=\"collaboration\">Collaboration</h2>\n<p>The frontend engineer sits at the busiest seam in product development. With\ndesigners, the work is a negotiation: pushing back when a mockup ignores the\nloading state or fails contrast, and translating pixels into a component system\nthat scales. With backend engineers, the contract is the API shape, and the\nrecurring fight is over-fetching, chatty endpoints, and who owns pagination and\nerror formats; a frontend engineer who reads an OpenAPI spec and proposes a\nbetter response shape saves both sides weeks. With product managers, they surface\nthe cost of &quot;small&quot; requests that hide loading states and edge cases. UX\nresearchers close the loop on how the built interface actually performs. Healthy\nteams treat the design system as shared infrastructure.</p>\n","wordCount":120},{"heading":"Ethics","id":"ethics","markdown":"The frontend is where dark patterns get implemented, which makes the frontend\nengineer the last line of defense and a willing accomplice by default. The\nduties: refuse the confirm-shaming dialog, the pre-checked consent box, the\ncancel flow buried six clicks deep, and the cookie banner engineered so \"accept\nall\" is the only easy path. Accessibility is an ethical obligation — an interface\na blind user can't operate excludes them from services they may have no\nalternative to. Performance is an equity issue: a bloated bundle taxes the\ncheapest phones and worst networks hardest, often the poorest users. And the\ndata collected through the interface should be the minimum the product needs,\ndisclosed honestly.","html":"<h2 id=\"ethics\">Ethics</h2>\n<p>The frontend is where dark patterns get implemented, which makes the frontend\nengineer the last line of defense and a willing accomplice by default. The\nduties: refuse the confirm-shaming dialog, the pre-checked consent box, the\ncancel flow buried six clicks deep, and the cookie banner engineered so &quot;accept\nall&quot; is the only easy path. Accessibility is an ethical obligation — an interface\na blind user can&#39;t operate excludes them from services they may have no\nalternative to. Performance is an equity issue: a bloated bundle taxes the\ncheapest phones and worst networks hardest, often the poorest users. And the\ndata collected through the interface should be the minimum the product needs,\ndisclosed honestly.</p>\n","wordCount":114},{"heading":"Scenarios","id":"scenarios","markdown":"**A page that feels slow but \"passes\" in the lab.** Lighthouse scores well, yet\ntickets say the dashboard is sluggish. Field data (RUM) shows INP is terrible at\nthe 75th percentile on Android. The Performance panel reveals one long task:\nevery keystroke in a filter box re-renders a 10,000-row table. Three moves fix\nit — debounce the input, virtualize the table, and memoize the row so unchanged\nrows skip reconciliation. INP drops from 600 ms to under 100 ms. Lab medians hid\na tail that real low-end devices live in.\n\n**The \"just add a tooltip\" request.** Product wants a tooltip on an icon. The\nexpert doesn't reach for a div with a hover handler: hover excludes touch and\nkeyboard users, the content can be clipped by `overflow: hidden`, and a naive\nbuild isn't announced to screen readers. They use a headless primitive handling\nfocus, escape-to-close, `aria-describedby`, and viewport collision — the dozen\naccessibility edge cases hiding behind a five-minute ticket.\n\n**Choosing where filter state lives.** A search page has filters, a page number,\nand a sort order. A junior puts them in a global store; the URL never changes.\nThe expert moves all of it into the URL query string. Now the result is\nshareable, the back button works, a reload restores the exact view, and the\nserver renders the right page on first load — one source of truth instead of a\nclass of state-sync bugs.","html":"<h2 id=\"scenarios\">Scenarios</h2>\n<p><strong>A page that feels slow but &quot;passes&quot; in the lab.</strong> Lighthouse scores well, yet\ntickets say the dashboard is sluggish. Field data (RUM) shows INP is terrible at\nthe 75th percentile on Android. The Performance panel reveals one long task:\nevery keystroke in a filter box re-renders a 10,000-row table. Three moves fix\nit — debounce the input, virtualize the table, and memoize the row so unchanged\nrows skip reconciliation. INP drops from 600 ms to under 100 ms. Lab medians hid\na tail that real low-end devices live in.</p>\n<p><strong>The &quot;just add a tooltip&quot; request.</strong> Product wants a tooltip on an icon. The\nexpert doesn&#39;t reach for a div with a hover handler: hover excludes touch and\nkeyboard users, the content can be clipped by <code>overflow: hidden</code>, and a naive\nbuild isn&#39;t announced to screen readers. They use a headless primitive handling\nfocus, escape-to-close, <code>aria-describedby</code>, and viewport collision — the dozen\naccessibility edge cases hiding behind a five-minute ticket.</p>\n<p><strong>Choosing where filter state lives.</strong> A search page has filters, a page number,\nand a sort order. A junior puts them in a global store; the URL never changes.\nThe expert moves all of it into the URL query string. Now the result is\nshareable, the back button works, a reload restores the exact view, and the\nserver renders the right page on first load — one source of truth instead of a\nclass of state-sync bugs.</p>\n","wordCount":239},{"heading":"Related Occupations","id":"related-occupations","markdown":"A frontend engineer is a software engineer specialized toward the client and the\nhuman in front of it, trading distributed-systems depth for rendering,\naccessibility, and perceived performance. The backend engineer owns the other\nside of the API contract. UX designers hand off the intent the frontend makes\nreal, and UX researchers test whether it worked. Mobile developers face the same\nclient-side state and performance problems against native constraints rather\nthan the browser. Product managers supply the why the interface expresses.","html":"<h2 id=\"related-occupations\">Related Occupations</h2>\n<p>A frontend engineer is a software engineer specialized toward the client and the\nhuman in front of it, trading distributed-systems depth for rendering,\naccessibility, and perceived performance. The backend engineer owns the other\nside of the API contract. UX designers hand off the intent the frontend makes\nreal, and UX researchers test whether it worked. Mobile developers face the same\nclient-side state and performance problems against native constraints rather\nthan the browser. Product managers supply the why the interface expresses.</p>\n","wordCount":82},{"heading":"References","id":"references","markdown":"- *Refactoring UI* — Adam Wathan & Steve Schoger\n- *Inclusive Components* — Heydon Pickering\n- *High Performance Browser Networking* — Ilya Grigorik\n- web.dev (Core Web Vitals guidance) — Google\n- WCAG 2.2 — W3C Web Accessibility Initiative\n- MDN Web Docs — Mozilla","html":"<h2 id=\"references\">References</h2>\n<ul>\n<li><em>Refactoring UI</em> — Adam Wathan &amp; Steve Schoger</li>\n<li><em>Inclusive Components</em> — Heydon Pickering</li>\n<li><em>High Performance Browser Networking</em> — Ilya Grigorik</li>\n<li>web.dev (Core Web Vitals guidance) — Google</li>\n<li>WCAG 2.2 — W3C Web Accessibility Initiative</li>\n<li>MDN Web Docs — Mozilla</li>\n</ul>\n","wordCount":34}],"computed":{"wordCount":2080,"readingTimeMinutes":9,"completeness":1,"backlinks":["backend-engineer","mobile-developer","ux-designer","web-developer"],"verified":false,"aiDrafted":true,"unverifiedAiDraft":true},"git":{"created":"2026-06-26","updated":"2026-06-26","revisions":2,"authors":[{"name":"soul-atlas","commits":2}],"timeline":[{"date":"2026-06-26","author":"soul-atlas"},{"date":"2026-06-26","author":"soul-atlas"}]},"citation":{"apa":"soul-atlas (2026). Frontend Engineer [SOUL]. SOUL Atlas. https://soul-atlas.github.io/occupations/frontend-engineer","bibtex":"@misc{soulatlas-frontend-engineer,\n  title        = {Frontend Engineer},\n  author       = {soul-atlas},\n  year         = {2026},\n  howpublished = {SOUL Atlas},\n  note         = {SOUL.md, version 2026-06-26},\n  url          = {https://soul-atlas.github.io/occupations/frontend-engineer}\n}","text":"soul-atlas. \"Frontend Engineer.\" SOUL Atlas, 2026. https://soul-atlas.github.io/occupations/frontend-engineer."}}