There's a recurring genre on engineering social media — a backend engineer or a systems person declaring that frontend work is trivial. Just HTML and CSS. A border, a button, a margin. The implication is that anyone with a real engineering mind would obviously be doing the harder thing on the other side of the API.
I've spent ten years in fullstack roles, and I've watched this take repeat enough times to notice the pattern around it. The same engineers who declare frontend easy are the ones who reroute every CSS ticket. The same engineers who insist "the frontend just renders what the backend gives it" are the ones who can't get a navbar to render correctly when they try. The mismatch is worth examining — not because it makes anyone wrong, but because it's data about what the work actually requires.
So what does the work actually require? Most of it isn't visible until you've shipped product into production for real users on real devices. A short list of the surfaces I've watched eat a senior backend engineer alive when they try to pick them up casually:
- Accessibility. WCAG conformance isn't a styling concern. It's a discipline of semantic HTML, focus management, screen-reader testing, keyboard navigation, and color contrast — all of it verified against assistive technology that you actually have to run. I led frontend accessibility on Michigan's React modernization of unemployment insurance for 270,000 residents across 2,000+ pages. The conformance bar was set by federal law, not preference, and the testing involved caseworkers running screen readers on five-year-old machines. The "just add aria-label" instinct doesn't survive a real audit.
- Performance under real-world conditions. A modern frontend operates against measured budgets — LCP, INP, CLS — governed by what a user on a flaky connection and a five-year-old phone can actually load. Hitting them requires bundle analysis, code-splitting strategy, font-loading discipline, image-pipeline decisions, and a working understanding of where the rendering critical path lives. None of which is CSS.
- State coordination at scale. A modern React app coordinates server state, client state, optimistic updates, derived state, and form state — often across views, often with race conditions that are subtle until they aren't. Reasoning about cache invalidation in TanStack Query is the same cognitive shape as reasoning about cache invalidation in a backend service. The "frontend just renders" framing collapses the moment you have to explain why three components are stale at slightly different times.
- The cross-device matrix. Frontend ships into a multiplicative test surface — iOS Safari quirks, Android browser variants, hybrid devices that report a fine pointer but use touch, screen readers with their own rendering rules, RTL scripts, locale-specific typography. The closest analogue in backend work is multi-region failover, and that's a different shape of complexity entirely.
- Motion and interaction. Done well, motion is the layout — how the product communicates state, hierarchy, and consequence. Done badly, it kills perceived performance and induces nausea. The discipline is part visual judgment, part physics, part frame-budget engineering, part empathy for the human nervous system. None of it is CSS in the meme sense.
- The build and tooling stack. Modern frontend toolchains are themselves a systems-engineering surface — bundlers, transformers, source maps, type-checking pipelines, monorepo coordination, design-token systems, MDX pipelines, edge-runtime deployment. The toolchain alone is more complex than most backend deployment pipelines I've worked in.
That's six items, picked because each one is large enough to absorb a senior career on its own. The work is real, and it doesn't compress into a stylesheet.
The pattern shows up most clearly when teams try to redistribute frontend work to engineers who don't have the instinct. In 2021 I was staffed onto FedNow at the Federal Reserve — a Salesforce Lightning Web Components build with hard governance constraints, including WCAG accessibility conformance for a regulated payments interface. My initial access was scoped to CSS only: no HTML, no JavaScript, no LWC component layer. The team was new to the contractor relationship and the regulated environment didn't yet trust the broader surface area.
The first MVP component the team needed was a navbar. The senior backend engineer assigned to it spent weeks fighting it and couldn't ship. I asked if I could try, the team agreed, and I built it from scratch to a production-ready state in a few days. The work was foundational, not cosmetic — the navbar and its related functionality were the first real frontend in the codebase, which meant the architecture and design patterns I established on it would shape the entire frontend system that came after. Those decisions had to be made right; they shaped the delivery of the rest of the project.
Access restrictions came off immediately after I shipped the navbar. From there I built out the frontend system end-to-end: a reusable component library, advanced data tables with custom functionality, and a custom form wizard that was reusable across the many forms the app required. I carved out a niche that was vital across the software-development lifecycle of that project and helped ship millions of dollars' worth of work on an instant-payment rail that would go on to move trillions in settlement flows. The client asked for me by name on every contract extension; my colleagues had taken to calling me Frontend Jesus. The project wouldn't have shipped without that frontend delivery.
The lesson I took from it isn't that the backend engineer was bad. They were excellent at the work they were excellent at. The lesson is that frontend instinct is a separate discipline, and the work was sitting there waiting for someone who had it. When the discipline is treated as decorative, the work doesn't get done. When it's recognized as a specialization, the right person picks it up and the product ships.
I'm a fullstack engineer by training — I've shipped backend services, database integrations, automated pipelines, and the cloud infrastructure underneath all of it. The reason I land on frontend on most projects isn't that backend work isn't interesting; it's that on most teams I've shipped with at scale, the frontend was the under-resourced surface. The work was sitting there, and senior engineers who can hold a user-facing product to a serious bar are scarcer than they should be. There's outsized leverage in being the engineer who closes that gap, and that's been true on every project I've shipped with weight: Michigan unemployment, the IRS modernization, FedNow, the ASU mobile app.
The companies that treat frontend as a competitive advantage are the ones whose products feel like products. Stripe didn't reach the position it has on backend uniqueness; the API is excellent, but so is everyone else's. The advantage is the developer experience — the documentation, the dashboard, the response shape, the error messages, the time-to-first-success — frontend at a depth most companies don't invest in. Linear trades on the same axis. So does Vercel. So does Notion. The companies that treat the surface as a formality ship surfaces that feel like formalities.
Frontend is a discipline. The work has weight. The engineers who do it well know systems, performance, accessibility, motion, state, and the human end of the stack as carefully as any backend engineer knows distributed transactions. Don't underestimate your frontend talent. The companies that recognize the depth early get the leverage; the ones that don't ship products that look like they didn't.