The moment I fell in love with frontend development was the moment I discovered the
style.css file in WordPress themes. I could (can!) change a handful of lines and totally change the look and feel of a website—and that, in turn, can alter the way you feel about a piece of writing, make you feel more comfortable buying tickets to an event, or increase the likelihood youʼll share something with your friends. Frontend development is at the intersection of art and logic, business and expression, left brain and right brain, design and nerdery. I love it.
“Frontend development is at the intersection of art and logic, business and expression, left brain and right brain, design and nerdery. I love it.”
card component does all the stuff your real-life card needs to do. Your
form component does forms the way your website needs to do forms.
This style of frontend development has really become full-stack development, and components are at the heart of it—so letʼs get into how they work.
Say I’m working on an explore page for a social coding platform. Naturally I have a
button component, an
icon component; and I’ll use both in my
card component. My
card component then lives in a
grid component, which lays them out and paginates them. The
header component has a
searchbar component and a
usermenu component. The
sidebar component has a
navigation component and an
/explore/tennessee/, render this particular set of components.”
Now that I’m dealing with URLs myself, I’m essentially the architect of the entire site. Like I told ya, a whole new haystack of responsibility. I’m hesitant to pass judgement on whether this is a good or bad thing. It’s more a shifting of control. If you like the control, it might be great. If you don’t, it might feel like you’re being stretched even thinner because you need to know and be responsible for even more than before.
fetch it when the component renders.)
In a stack I’m working with right now, the frontend is in React, the API is in GraphQL, and the data is queried through Apollo Client. We use a special hook in the React components to run the queries to fetch the data we need, and another special hook when we need to change that data. Guess who does that work. Is it another category of developer who specializes in data layer work? Nope. This is now part of the domain of frontend development.
Speaking of data, there’s a lot more data a website has to deal with that doesn’t come from a database or an API. Which tab is active right now? Is this modal dialog open or closed? Which bar of this accordion is expanded? Is this message bar in an error state or a warning state? How many pages are you paginated in? Frontend developers have been dealing with this kind of state for a long time—but it’s also gotten us into trouble before. A modal dialog can be open with a modifier class like
<div class="modal is-open">, and toggling that class is easy enough with
modal.classList.toggle(".is-open");. But that’s a purely visual treatment. How does anything else on the page know if that modal is open or not, in case it needs to?
In a lot of jQuery-style apps, you would ask the DOM. The DOM is the source of truth. All sorts of problems stem from this architecture, from a simple class name change destroying functionality in weirdly insidious ways (like adding an innocuous-seeming
<span>, which breaks a selector on the login button, making it impossible to log in) to hard-to-reason-about application logic making bug fixing a difficult proposition.
Not only has the to-do list grown longer, but the central questions are also bigger.
Img—can we scaffold these out? Should we start with some kind of design framework on top of the base framework? Should we look at a third-party component library? What’s the client state we might need? How much of this state can be handled at the individual component level, and how much needs to be higher-level? How much of this data can we get at the individual component level, and how much should come down from above? With responsive image syntax, lazy loading, multiple formats, and CDNs to grapple with, how are we going to handle images (the web’s heaviest assets)?
Frontend developers responsible for architecture and data are asking themselves questions that once would have been answered by backend developers. What tools are we going to use for routing? How are we dealing with caching? What about offline support? How is the login/auth system going to work?
Meanwhile, frontend developers more focused on design ask: How much of the styling of this component should be scoped to itself, and how much should come from more global styles? Which styling solutions should we be looking at? Is Sass still the right tool for the job in this new world of components? How can our design be both consistent and supportive of creativity and flexibility?
We handle this growing responsibility in different ways. Even though we all technically fall within the same big-tent title, many frontend developers wind up specializing. Often, we don’t have a choice. The term “unicorn” once described the extremely rare person who was good at both frontend and backend development, but these days it’s just as rare to find people skilled at the full spectrum of frontend development. In fact, the term “full stack” has largely come to mean “a frontend developer who does a good amount of the stuff a backend developer used to do.”
We’ve also invented systems to ease the burden. It’s no wonder design systems have taken off in recent years; we’re already building components, so thinking about design in a systematic way is a natural fit. A good design system makes things easier. With design and functionality choices already made, frontend development can focus on composing components—which is still plenty of work, but perhaps less overwhelming.
How we talk about building websites has changed a lot in the last decade. Some of my earliest experiences with web development were with WordPress, which needs a web server to run, is written in PHP, and stores data in a MySQL database. As much as WordPress has evolved over the years, the stack—which uses the acronym LAMP (or Linux, Apache, MySQL, and PHP)—is still the same. LAMP is made up of backend technologies; as a frontend developer, almost nothing about that stack is relevant to me.
In 2019, Shawn Wang coined the acronym STAR, or design System, TypeScript, Apollo, and React, to describe a new stack. It represents an incredible shift—it’s a way of talking about the stack that powers a website that’s based entirely on frontend technologies. I couldn’t have imagined this in my wildest dreams in 2009, and I can’t even begin to guess what 2029 will look like.
Being a frontend developer requires an ever-larger grab bag of skills. It’s the natural outcome of the web getting bigger. As more people use the web, as the internet economy expands, and as browsers gain more capabilities and grow more complex, our expectations of what’s possible on the web grow with them.
As browsers gain more capabilities and grow more complex, our expectations of what’s possible on the web grow with them.
We’ve already reached a point where most aren’t familiar with the entire growing pile of frontend responsibilities. Many design-focused developers who excel at creative and well-implemented HTML and CSS continue to do well at their jobs, but postings for that kind of role are dwindling. Instead, employers are increasingly looking for developers adept at particular frameworks. Systems-focused developers, as well as entire agencies, specialize in helping other companies build and implement design systems. Data-focused developers feel most at home making data flow through a website—getting hot and heavy with business logic. All of these people might have “frontend developer” on their business cards, but their responsibilities, and even their expectations of their work, might differ greatly, which also impacts the hiring process. In time, I think we’ll find better ways to talk about these distinctions, and companies will get better at spelling out exactly what skills they’re looking for in a frontend developer.
If you feel like you’re falling behind, you’re not alone. Everybody has weak spots, or entire areas they just don’t know the first dang thing about. The good news is that not only can you specialize, you probably should—in fact, you’ll probably end up specializing to some degree whether you plan to or not.
For now, frontend developers have this in common: When we type a
<button>, we’re quite literally putting a button into a browser window for users to interact with. When we adjust a color, we’re adjusting exactly what our sighted users see. That’s not so different from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience.
While backend developers may (and should, and often do) care deeply about a site’s users, they are, as Monica Dinculescu once told me, “outsourcing that responsibility.” We frontend developers take on the role of caring for users most directly. And our users live in a world that’s much bigger than their browsers. They speak different languages. They want different things. They’re trying to solve different problems. They have different abilities. They have different levels of urgency. They’re also why we build things at all. They’re who I’m trying to impress with my mad CSS skills. Who I’m trying to get to buy my widget. Who my business charts hinge upon. Whose reaction can sway my emotions like yarn in the breeze.
Being a frontend developer puts us between the thing we’re building and the people we’re building it for—and that’s a place some of us really enjoy being, even if it means taking on ever-larger bundles of responsibility from that big haystack of work. Weighty stuff, isn’t it?