This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.”
The moment I fell in love with front-end development was when I discovered the
style.css file in WordPress themes. That’s where all the magic was (is!) to me. I could (can!) change a handful of lines in there and totally change the look and feel of a website. It’s an incredible game to play.
By fiddling with HTML and CSS, I can change the way you feel about a bit of writing. I can make you feel more comfortable about buying tickets to an event. I can increase the chances you share something with your friends.
That was well before anybody paid me money to be a front-end developer, but even then I felt the intoxicating mix of stimuli that the job offers. Front-end development is this expressive art form, but often constrained by things like the need to directly communicate messaging and accomplish business goals.
Front-end development is at the intersection of art and logic. A cross of business and expression. Both left and right brain. A cocktail of design and nerdery.
I love it.
Looking back at the courses I chose from middle school through college, I bounced back and forth between computer-focused classes and art-focused classes, so I suppose it’s no surprise I found a way to do both as a career.
The term “Front-End Developer” is fairly well-defined and understood. For one, it’s a job title. I’ll bet some of you literally have business cards that say it on there, or some variation like: “Front-End Designer,” “UX Developer,” or “UI Engineer.” The debate around what those mean isn’t particularly interesting to me. I find that the roles are so varied from job-to-job and company-to-company that job titles will never be enough to describe things. Getting this job is more about demonstrating you know what you’re doing more than anything else¹.
The title variations are just nuance. The bigger picture is that as long as the job is building websites, front-enders are focused on the browser. Quite literally:
- front-end = browsers
- back-end = servers
Even as the job has changed over the decades, that distinction still largely holds.
As “browser people,” there are certain truths that come along for the ride. One is that there is a whole landscape of different browsers and, despite the best efforts of standards bodies, they still behave somewhat differently. Just today, as I write, I dealt with a bug where a date string I had from an API was in a format such that Firefox threw an error when I tried to use the
Even across that landscape of browsers, just on desktop computers, there is variance in how users use that browser. How big do they have the window open? Do they have dark mode activated on their operating system? How’s the color gamut on that monitor? What is the pixel density? How’s the bandwidth situation? Do they use a keyboard and mouse? One or the other? Neither? All those same questions apply to mobile devices too, where there is an equally if not more complicated browser landscape. And just wait until you take a hard look at HTML emails.
That’s a lot of unknowns, and the answers to developing for that unknown landscape is firmly in the hands of front-end developers.
The most important aspect of the job? The people that use these browsers. That’s why we’re building things at all. These are the people I’m trying to impress with my mad CSS skills. These are the people I’m trying to get to buy my widget. Who all my business charts hinge upon. Who’s reaction can sway my emotions like yarn in the breeze. These users, who we put on a pedestal for good reason, have a much wider landscape than the browsers do. They speak different languages. They want different things. They are trying to solve different problems. They have different physical abilities. They have different levels of urgency. Again, helping them is firmly in the hands of front-end developers. There is very little in between the characters we type into our text editors and the users for whom we wish to serve.
Being a front-end developer puts us on the front lines 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.
That’s some weighty stuff, isn’t it? I haven’t even mentioned React yet.
The “we care about the users” thing might feel a little precious. I’d think in a high functioning company, everyone would care about the users, from the CEO on down. It’s different, though. When we code a
<button>, we’re quite literally putting a button into a browser window that users directly interact with. When we adjust a color, we’re adjusting exactly what our sighted users see when they see our work.
That’s not far off from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience. While a back-end developer might care deeply about the users of a site, they are, as Monica Dinculescu once told me in a conversation about this, “outsourcing that responsibility.”
This isn’t quite fair though. HTML is the very first file that browsers parse before they do the rest of the work needed to build the site. That firstness is unique to HTML and a vital part of making websites fast.
In fact, if the HTML was the only file to come across the network, that should be enough to deliver the basic information and functionality of a site.
That philosophy is called Progressive Enhancement. I’m a fan, myself, but I don’t always adhere to it perfectly. For example, a
<form> can be entirely functional in HTML, when it’s
While the web almanac might show us that only 5% of the top-zillion sites use React compared to 85% including jQuery, those numbers are nearly flipped when looking around at front-end development job requirements.
I’m sure there are fancy economic reasons for all that, but jobs are as important and personal as it gets for people, so it very much matters.
- Translate designs into code
- Think in terms of responsive design, allowing us to design and build across the landscape of devices
- Build systemically. Construct components and patterns, not one-offs.
- Apply semantics to content
- Consider accessibility
- Worry about the performance of the site. Optimize everything. Reduce, reuse, recycle.
Just that first bullet point feels like a college degree to me. Taken together, all of those points certainly do.
This whole list is a bit abstract though, so let’s apply it to something we can look at. What if this website was our current project?
Our brains and fingers go wild!
- Let’s build the layout with CSS grid.
- What fonts are those? Do we need to load them in their entirety or can we subset them? What happens as they load in? This layout feels like it will really suffer from font-shifting jank.
- There are some repeated patterns here. We should probably make a card design pattern. Every website needs a good card pattern.
- That’s a gorgeous color scheme. Are the colors mathematically related? Should we make variables to represent them individually or can we just alter a single hue as needed? Are we going to use custom properties in our CSS? Colors are just colors though, we might not need the cascading power of them just for this. Should we just use Sass variables? Are we going to use a CSS preprocessor at all?
- The source order is tricky here. We need to order things so that they make sense for a screen reader user. We should have a meeting about what the expected order of content should be, even if we’re visually moving things around a bit with CSS grid.
- The photographs here are beautifully shot. But some of them match the background color of the site… can we get away with alpha-transparent PNGs here? Those are always so big. Can any next-gen formats help us? Or should we try to match the background of a JPG with the background of the site seamlessly. Who’s writing the
alttext for these?
- There are some icons in use here. Inline SVG, right? Certainly SVG of some kind, not icon fonts, right? Should we build a whole icon system? I guess it depends on how we’re gonna be building this thing more broadly. Do we have a build system at all?
- I’m glad the designer thought of not just the “desktop” and “mobile” sizes but also tackled an in-between size. Those are always awkward. There is no interactivity information here though. What should we do when that search field is focused? What gets revealed when that hamburger is tapped? Are we doing page-level transitions here?
I could go on and on. That’s how front-end developers think, at least in my experience and in talking with my peers.
A lot of those things have been our jobs forever though. We’ve been asking and answering these questions on every website we’ve built for as long as we’ve been doing it. There are different challenges on each site, which is great and keeps this job fun, but there is a lot of repetition too.
Allow me to get around to the title of this article.
I like it, this idea of components. It allows you and your team to build the abstractions that make the most sense to you and what you are building.
Card component does all the stuff your card needs to do. Your
All this custom component creation makes me a site-level architect in a way that I didn’t use to be. Here’s an example. Of course I have a
Button component. Of course I have an
Icon component. I’ll use them in my
Card component. My
Card component lives in a
Grid component that lays them out and paginates them. The whole page is actually built from components. The
Header component has a
SearchBar component and a
UserMenu component. The
Sidebar component has a
Navigation component and an
Like I told ya, a whole pile of new responsibility.
fetch it when the component renders. In a stack I’m working with right now, the front end is in React, the API is in GraphQL and we use Apollo Client to work with data. 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 some other kind of developer that specializes in this data layer work? No, it’s become the domain of the front-end developer.
Speaking of data, there is all this other data that a website often has to deal with that doesn’t come from a database or API. It’s data that is really only relevant to the website at this moment in time.
- 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 warning state?
- How many pages are you paginated in?
- How far is the user scrolled down the page?
Front-end developers have been dealing with that kind of state for a long time, but it’s exactly this kind of state that has gotten us into trouble before. A modal dialog can be open with a simple modifier class like
<div class="modal is-open"> and toggling that class is easy enough with
.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? Does it ask the DOM? In a lot of jQuery-style apps of yore, yes, it would. In a sense, the DOM became the “source of truth” for our websites. There were all sorts of problems that stemmed from this architecture, ranging from a simple naming change destroying functionality in weirdly insidious ways, to hard-to-reason-about application logic making bug fixing a difficult proposition.
There is expanding responsibility in the checklist of things to do, but there is also work to be done in piecing it all together. 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 be gotten at the individual component level and how much should be percolated from above? Design itself comes into play. How much of the styling of this component should be scoped to itself, and how much should come from more global styles?
It’s no wonder that design systems have taken off in recent years. We’re building components anyway, so thinking of them systemically is a natural fit.
Let’s look at our design again:
A bunch of new thoughts can begin!
- Where are those recipes coming from? Can we get a GraphQL API going so we can ask for whatever we need, whenever we need it?
- Maybe we should pick a CMS that has an API that will facilitate the kind of front-end building we want to do. Perhaps a headless CMS?
- What are we doing for routing? Is the framework we chose opinionated or unopinionated about stuff like this?
- What are the components we need? A
Img… can we scaffold these out? Should we start with some kind of design framework on top of the base framework?
- What’s the client state we might need? Current search term, current tab, hamburger open or not, at least.
- Is there a login system for this site or not? Are logged in users shown anything different?
- Is there are third-party componentry we can leverage here?
- Maybe we can find one of those fancy image components that does blur-up loading and lazy loading and all that.
We’ve already reached the point where most front-end developers don’t know the whole haystack of responsibilities. There are lots of developers still doing well for themselves being rather design-focused and excelling at creative and well-implemented HTML and CSS, even as job posts looking for that dwindle.
There are systems-focused developers and even entire agencies that specialize in helping other companies build and implement design systems. There are data-focused developers that feel most at home making the data flow throughout a website and getting hot and heavy with business logic. While all of those people might have “front-end developer” on their business card, their responsibilities and even expectations of their work might be quite different. It’s all good, we’ll find ways to talk about all this in time.
In fact, how we talk about building websites has changed a lot in the last decade. Some of my early introduction to web development was through WordPress. WordPress needs a web server to run, is written in PHP, and stores it’s data in a MySQL database. As much as WordPress has evolved, all that is still exactly the same. We talk about that “stack” with an acronym: LAMP, or Linux, Apache, MySQL and PHP. Note that literally everything in the entire stack consists of back-end technologies. As a front-end developer, nothing about LAMP is relevant to me.
Shawn Wang coined a term for a new stack this year: STAR or Design System, TypeScript, Apollo, and React. This is incredible to me, not just because I kind of like that stack, but because it’s a way of talking about the stack powering a website that is entirely front-end technologies. Quite a shift.
I apologize if I’ve made you feel a little anxious reading this. If you feel like you’re behind in understanding all this stuff, you aren’t alone.
In fact, I don’t think I’ve talked to a single developer who told me they felt entirely comfortable with the entire world of building websites. Everybody has weak spots or entire areas where they just don’t know the first dang thing. You not only can specialize, but specializing is a pretty good idea, and I think you will end up specializing to some degree whether you plan to or not. If you have the good fortune to plan, pick things that you like. You’ll do just fine.
The only constant in life is change.
– Heraclitus – Motivational Poster – Chris Coyier
Great write-up Chris! Thanks.
A great read. And thanks for the signoff. My imposter syndrome started to kick in by the end.
What a great read, Chris! Such a nicely put together article.
Thanks Chris this for this article.
While reading I was in another world. Very well written.
React is the oldest of the big frameworks and it shows.
Popularity is the simplicity. Great for noobs. But horribly outdated in so many ways compared to Angular, Svelte, Vue
Angular is older than React.
Vue is literally a mix of Angular and React.
Svelte is the only framework trying something completely different, and that’s most likely the reason it hasn’t taken hold.
As for React being great for noobs, Vue is widely considered vastly easier than React, and React is already vastly easier than Angular.
Great article on this topic as always. I’d say security is another growing responsibility as the front-end gets more complex.
That was 2015. I learnt of Node and npm from Zell Liew’s ‘Gulp for Beginners’ article on here (and I loved using Gulp!). Then in 2016 I read about the MEAN stack, Meteor, React, ES6, Babel, Webpack, modules etc. etc., and felt more confused than ever. I found the ShopTalk Show podcast and felt a bit better (which reminds me that I need to start listening to that more!).
I feel like half the battle is understanding what does what, the problems it solves, and why or when you’d reach for it. Once you start to understand some of the things it helps the other things fall into place and you can build on the knowledge. I’m still behind on a lot of this stuff, and sometimes it’s overwhelming, but other times it’s empowering. There’s so much a front-end dev can do – JAMstack, Progressive Web Apps, SVG animations, the canvas API… you can pretty much build whatever you want and it’s all happening on the web, which has only become more and more convenient to access. Even as a kid in the early 2000s I thought there was something magical about hitting a website and finding out that it’s not really a website at all but some sort of interactive art or game.
Sometimes I’m only doing design work, sometimes I’m only coding, but most of the time I feel more like a front-end designer, a term coined by Brad Frost in this fantastic article ➜
It makes me happy to hear someone else say that CSS is their favorite as it’s always been my favorite as well and apparently that’s not a common thing.
You’re in good company around here. :)
one of the best post i ever read about front-end. Thanks
Absolutely fantastic piece Chris. As a designer with next to no development skill, it gave me a whole new appreciation for the front end.
Geez, I’m trying to learn front-end Web by myself and this article is making me feel nauseated. How’s a freelance developer suppose to keep up with all this and find work? It’s getting ridiculous.
Great article and sums up my current feelings. In a word; fatigued. I’m a full stack developer and one of my front end projects is a single page web application built with AngularJs. A few years in and having become quite proficient, my boss suggests we should be using Angular2.0 instead. Suddenly I’m expected to be able to write in Typescript, wrap my head around components and effectively learn an entirely new framework from scratch, just to produce exactly the same web app. (I said no). But from then on I have tried to keep up (read catch up) with all the new web technologies so I wouldn’t feel so hopelessly out of touch, but to be very honest there simply isn’t the time. And now on top of all the rest you have cloud based services that can provide a whole new way of creating web applications and all the rest. It’s almost impossible just to keep up with what is out there and what they do, to know if there is a better way to solve the problem at hand.
At this point as a front end developer, full stack developer? I don’t even know how to describe what we do anymore. All I can say is, we basically do it all.
Great article Chris. I couldn’t agree more. For myself who started out with and loving HTML and CSS, front-end development has gotten seemingly complex. Add on thinking about CMS approaches with client projects and setting up access for them to make edits themselves (then training them), and it’s a lot to keep up with. The responsibilities have grown greatly. I’m not quite sure the respect for the needed knowledge in these roles by employers have grown with it as titles seem to stuff in “do everything” for mediocre salaries from what I’ve observed in my geo area. I do question at times if all these changes are really necessary for basic website projects, but there isn’t a lack of options which I suppose is a good thing too. I still love this work, but there’s no doubt that it’s often overwhelming to keep up with especially with so little time to study.
Wonderful read! It’s so nice to know I’m not alone in feeling behind or lacking in certain areas. I like to think I know enough to get any job done thrown at me, but I definitely feel I should be brushing up on newer technologies.
Also, that but about the PHP include()’s gave me a chuckle and a few flashbacks to early PHP programming for me, so thanks for that, Chris!
This is the type of mental therapy I needed. Thank you, Chris, for teasing out the gotchas of our profession into this much needed and priceless write-up.
Thanks for this Chris, it’s reassuring to hear form someone like yourself. I’ve worked this role for nearly 10 years and have been on the job hunt recently. The laundy-list of expectations and different tech that get asked of FED job descriptions is a bit overwhelming at times even as a practitioner.
I feel like it’s gotten confused as it expanded and incorporated more traditional programmer ideals. When it’s come to interviews I can talk passionately about design, users, browsers and all the things you mention above, but now on the day it’s all about Leetcode and Dijkstra. So that’s now on the list.
WOW, just WOW. Can I nominate this article as my top 1 article of 2020? Love it, so much to think about. Thank you for putting in words what is hard to express!
FED career is very similar with role of a supporting actor in a movie. A supporting actor is the most critical part of a movie. His/Her acting skills and passion for playing a character is or may exceed than lead hero. They wear many hats like uplifting the script, encouraging coactors, leave a long-lasting impression on audience. In terms of finances, character actors struggle a lot. Their success is mostly based on luck or good commercial script. In their free times, they do theatres, stge acting just to polish or sharpen their craft. On the other hand, A lead hero is already established in audiences mind through status symbol, box office hits etc. Similar to them, A backend developer has already gone through competitive education and experiences to design and build database systems. A frontend developers success is based on your job, how successfully you perform on the job and solve business requirements for your organization. Other things that contribute to your success is your hunger for the craft, sometimes luck and keeping sanity on your journey to become a FED. Cramming a JS framework will take you nowhere. Many people will play a part in your success in this field besides you.
Such a beautifully written article
Interesting article… I definitely felt like an imposter by the end.
Beyond components and state management, we also have the semantics side – which is cited – but it could be also combined with a lot of SEO techniques: from optimizing the markup to create a fancy structure to using microdata. I believe it may be inside the “performance” topic, because a good part of SEO optimizations come from making the website blazing fast for the user; so the responsability checklist keeps growing every time we think about it.
Nice read by the way Chris! Thank you for this awesome text.
Excellent post! Ironically, it took me 6 weeks to get around to reading it because it’s been buried behind 100 other tabs in my browser — I’m starting a greenfield personal project and decided to use React even though I’ve been doing exclusively Vue development for the past 2 years, so I’ve been getting up to speed with React and Redux and CSS-in-JS and etc. etc.
The reason I’m using React (even though I absolutely hate it compared to Vue!) is it feels like I should know it and that I’m missing out on something by not knowing it.
This article may have just saved that project — I guess I’ll stick with React, but on top of that I had just started reading Go tutorials thinking maybe I’d build the back end of this using it, rather than sticking to something I already know like Sanity, WordPress or Keystone, and if I had kept going on that I probably would have been permanently lost in the weeds.
I’ve been grappling with similar ideas for a while now. The responsibilities of frontend developers has continued to increase year on year while designers are expected to draw pretty pictures in Figma. As a UX designer, I’m desperate to use my skills in semantic HTML, CSS, animations and accessibility but no, I have to log endless defects to bash it into shape and sit on a backlog of enhancements that no one had time for.