What it Means to be a Front-End Developer in 2020 (and Beyond)

Do you ever think about what the front-end part of front-end developer really means? I once asked Eric Meyer (who has been building websites for nearly as long as there have been websites) if he knew what the term meant back in the very early days, and he said yes. So, it’s not a brand new title or position, but it’s certainly moved in scope over the years.

​​“Front-end” essentially means web browser. I consider myself a front-end developer, and I honestly wouldn’t hate it if you called me a web browser developer. But, that probably won’t  catch on (and sort of sounds like you build web browsers). As a front-end developer, you work very closely with web browsers and write the code that runs in them, specifically HTML, CSS, JavaScript, and the handful of other languages that web browsers speak (for instance, media formats like SVG). Or, perhaps even more commonly explained, code that ultimately gets processed into those languages that browsers understand. That’s your territory as a front-end developer! 

Browsers don’t exist alone, they run on a wide landscape of devices. We learned that through the era of responsive design. And most importantly: users use those browsers on those devices. Nobody is closer to the user than front-end developers. So front-end developers write code for people using browsers that run on a wide variety of devices.

​​Just dealing with this huge landscape of users, devices, and browsers is a job unto itself! I would think that it’s not every day that you think philosophically about your job title, and that’s fine; we’re just doing a little reflecting here with your ol’ grandpa Chris. 

​​If you’ve just graduated from a coding bootcamp and your experience building websites is somewhat narrow and new, you could be forgiven if you think of front-end development as “the React stuff” and back-end development as “the Node stuff” or “the Python stuff,” as are the hottest flavors these days. You aren’t wrong, either. React is generally used as a front-end framework (it’s literally JavaScript that runs in browsers). Node and Python are examples of languages that don’t really run in web browsers; they are built to run on web servers (uhh, computers). 

​​Stick around in this field for a while, and you’ll see these libraries, languages, build processes, and heck, even entire philosophies on how best to build websites come and go like a slow tide. 

​​You might witness some old-timer waving their fist from time to time, yelling that we should learn from the mistakes of the past. You could also witness some particularly boisterous youth waving their fists just as high, pronouncing the past an irrelevant context and no longer a useful talking point.

​​They’re both right, probably. As long as nobody is being nasty, it’s all part of the flow.

​​Things change. I find it to be true that many websites of today are more complex than websites of the past. Particularly the big ones. The social networks and media players. The travel booking sites. The eCommerce storefronts. The engineering tools. These sites started big and have only gotten bigger. They are economies onto themselves with massive teams supporting them. This complexity is a cause of change in web technology and a cause of friction between the new and old schools (if we can paint it that simply).

​​Many people that work in tech work for, essentially, a big website. And so we hear from these people most often. These people build tools. They write blog posts, they go on podcasts, they deliver talks. They help change technology itself, to suit their needs.

​​All the while, the “front-end” is still just the browser. The browsers languages, HTML, CSS, and JavaScript are still the core technologies at play. Those languages evolve, and so do the browsers themselves, but more slowly. They do quite the opposite of Silicon Valley’s favorite slogan: move fast and break things. They move slowly and very rarely break anything.

​​Being a front-end developer is still caring about users who use those browsers on those devices. Their experience is our job. The tooling just helps us do it, hopefully. 

​​So what are you doing as a front-end developer?

• ​​You’re executing the design such that it looks good on any screen
• ​​You’re applying semantics to content
• ​​You’re building UI abstractly such that you can re-use parts and styles efficiently
• ​​You’re considering the accessibility of what renders in the browser 
• ​​You’re concerned about the performance of the site, which means you’re dealing with how big and how many resources are being used by the browser.

​​Those things have always been true, and always will be, since they are fundamentally browser-level concerns and that’s what front-end is. 

​​What’s changing is that the browser is capable of more and more work. There are all sorts of reasons for that, like browser APIs getting more capable, libraries getting fancier, and computers getting better, in general. Offloading work from the server to the browser has made more and more sense over the years (single page apps!). Although it’s interesting to watch the pendulum swing back (pre-rendered sites!) and find a middle ground (JAMstack!). 

​​Front-end development these days might also include:

• ​​Architecting the entire site from the tiniest component to entire pages up to the URL level
• ​​Fetching your own data from APIs and manipulate the data as needed for display
• ​​Dealing with the state of the site on your own
• ​​Mutating/changing data through user interaction and input and persist that data in state and back to the servers through APIs

​​Those are all things that can be done in the browser now, much to the widening eyes of this old developer. That’s a heck of a haystack of responsibility when you consider it’s on top of all the stuff you already have to do.

​​While that haystack of jobs tends to grow over the years, the guiding light we have as front-end developers hasn’t changed all that much. Our core responsibility is still taking care of users who use web browsers on devices. So we have to fetch some data. That’s cool, we’re doing it in service to building a fast, semantic, accessible page to serve our user’s needs. So we need to build a design system. That’s cool, we’re doing it to build an understandable interface for our users capable of evolving without creating an inconsistent mess. So we have to learn some new unfamiliar technology. Well, it’s our job to keep a watchful eye and make sure that new thing is ultimately there to better our site for users. 

​​Good luck!