Think like a front-end developer

December 15, 2023

The idea for this post came in 2018. Chris and Dave did a series on the Shop Talk Shop called, “Think Like a Front-End Developer.” I listened to several of those episodes and wanted to write my thoughts to answer the questions they asked their guests.

So I am pulling another idea from the backlog and making it a reality. I pulled together some of the common questions that they asked every guest.

Do you consider yourself a front-end developer?

Yes, I consider myself a front-end developer. But for several years, I have realized that the term front-end developer means different things to different people.

Around 2014/2015, I realized that front-end developer = JavaScript developer for many people. Or at least that is what it meant to people who were writing up job descriptions. The majority of the jobs that I saw for front-end developers meant that you had to be proficient in those frameworks. To be honest, I was not that excited about those frameworks.

Brad Frost coined the term “front-of-the-front-end-developer” several years ago. I think it does a good job of capturing the type of developer I am.

“A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.”

I unpacked this a few years ago to help describe what being a front-end developer means to me.

I started my career under the title of webmaster. I wore many hats as I was responsible for one site. I was a designer, developer, content strategist, and information architect. Later I started calling myself a web designer.

For me, that meant I was a designer who knew how to code. Most of the people that I followed–Dan Cederholm, Elliot Jay Stocks, Andy Clarke–all were designers who also coded their work. So I thought most people had that same understanding of what a web designer was.

I embraced the role of front-end developer in 2012. Although I wanted to still do both design and development, I realized that most places that employ Web professionals wanted to push you in one direction or another. I also had a personal epiphany.

I recognized there were still a lot of creative opportunities as I collaborated with the designers to help make their creative vision happen. I found that there was still a lot of joy in building out a design even when it was not my creative vision. I learned that I enjoyed the build process was the part of the project process that I most enjoyed.

What makes someone a front-end developer?

A front-end developer is the one that makes the design come alive. He or she is the person responsible for bringing the creative vision of the designer into being through code and can even push the design further by adding the interactivity or animation layer that the designer may not have even thought of.

A front-end developer has to think about a lot of different things to create the best experience for the user.

  • writing semantic HTML markup that is friendly to browsers, assistive technologies, search engines, and other environments that can consume the code
  • accessibility
  • thinking about how a user will experience the site and optimizing the useability of the interface
  • layout and how that layout changes to respond to the viewport that the user is interacting with your site
  • optimizing the performance of the front-end code and assets
  • animation and interactivity
  • make sure the site works across a spectrum of browsers and devices
  • keeping up with the ever-changing technologies that power the Web–HTML, CSS, and JavaScript

Can they not ____ and still be considered a front-end developer?

I think a successful front-end developer will have a breadth of those skills. I think if a front-end developer is not thinking about things like accessibility or performance, they are going to be less marketable and their work will not be up to the same level that those who are thinking about those things are. I think there is a different level of quality to a developer’s work if they are thinking broadly or taking the time to learn the new technologies and tools available to them.

But I will also say that not every developer is going to be at the same level in each of those areas. The reality is that there is too much to be able to be deep in everything. Most developers I know have a breadth of all those skills and then go deeper in 1-3 of those.

For example, I have been more focused on going deeper in the area of accessibility over the past four or five years. Though I have a lot of knowledge of performance, it is an area I know I could go much deeper in but have had to choose to focus on other areas that resonated more with me or I deemed as more important.

Ideal project/process

I think I know where my sweet spot is. so that I can make decisions about structure, semantics, etc from the very beginning.

It can be a real challenge to build on someone’s work especially if something new or unexpected comes from a client and that was not taken into account by another developer. It is hard enough when it is your work that you have to build upon. Even tougher when it was built by someone else with different methodologies and workflows.

I also like to work on projects where I have the space to add polish. A lot of time that polish will be in the form of animations. I love to be able to take a project to a new level with some animation.

And I think there has to be a right balance of animation. I tend to lean more toward a conservative approach to animation. I tend to like more subtle animation. I don’t necessarily think everything has to be animated into view as you scroll down the page.

I remember one project where I took it too far. As I stepped back, I decided to “edit” and cut back on the elements that I had fading in. The client liked the more subtle approach and so did I

My ideal project gives me enough time to experiment and play around with some ideas that may be abandoned to give the best experience in the end. Sometimes you just need to be able to build it to see if it works or not. Not all of those ideas work. And sometimes you encounter happy accidents along the way.

The greatest challenge in practice

To be honest, on a day-to-day basis, naming things is one of the biggest challenges. Other challenges are accessibility and performance. I know a lot of things in both of those areas but still don’t always feel confident in these things because there are so many things that I have to think about. I can’t be an expert in all things. And the scale of projects I work on does not allow me to bring in experts on the subject.

Keeping the CSS codebase as small as possible is another challenge. A lot of the projects I work on have custom layouts on each page and don’t always have similar patterns. So the challenge is how to not be writing CSS for each one that adds more and more weight to the CSS file which impacts performance. This can be a real challenge when you don’t get all the pages at once.

What battles will you fight?

I don’t tend to get drawn into the hot dramas on social media. I may have strong opinions but I keep them to myself. With age has come some wisdom. I recognize that there are always bigger stories behind someone’s take that I don’t know about. And I have come to realize that everyone is doing the best that they can. Or at least, I choose to assume that first about people.

I think the battles I fight in projects usually have to do with user experience. I tend to push back when asked to do something that I think will negatively affect the user. I don’t always win those battles but I try.

There are times when I wish I had more contact with the client and could lay out a case for them to consider. I try to lay out that case for the project managers or strategists I work with to pass along to the client.

I think more times than not when I have made a case, the client has agreed with my perspective. But it is not always the case. I have learned that sometimes you just need to implement something because it is the choice the person paying for it has made.

I will also push back on our designers when it comes to useability or user experience. Again, I have found it is much better to lay out a case than make it an opinion call. I have even built a prototype of what I thought might be a better solution to show the designer. That worked out well because she could see the functionality in action.

Approach to mockups

On a majority of projects I work on, I only have a desktop view mockup. The first thing I do is to look through all the pages and start identifying common blocks or components that will need to be built for WordPress. I try to compare and see if similar blocks could be one block with different variants.

Next, I start looking to see if there are elements that will need to be full-screen and try to figure out if I need a larger image. Or there have been times where there are curved paths that extend past the viewport so I will talk to the designer and come up with a strategy of how to handle that for screens wider than the mockup (usually 1440 to 1600px wide).

Next, I will try to identify pieces that I think are going to be a challenge to build. Modern CSS has eliminated a lot of the challenges I have had in the past so I love it that I rarely have to tell a designer that we can’t do that. More often than not, if they ask if something is going to be a problem, I tell them that we will figure out how to make it work.

As I am looking through a mockup, I already starting to think about layout strategies, look for opportunities to animate, and identify any patterns or backgrounds that may be a challenge to optimize or come up with a tiling solution. I am always looking at how to best optimize the experience.

I find myself involved in more design reviews these days than I used to be. This is a great opportunity to start engaging the designer earlier in the process. One thing I try to do is check color contrast to make sure we have an accessible design. And I might suggest how we might make something interactive. If I have some downtime, I may take the opportunity to build a prototype of something to get a jump on learning how to code it or just to be able to see what it is going to look like so I can have a conversation with the designer.

What is your approach to building layouts with CSS?

I was an early adopter of a mobile-first philosophy for building websites. The idea behind mobile-first is to prioritize smaller screens and then add on styles using media queries for larger viewport sizes. So your defaults take into account the smaller screen sizes for fonts, layout (usually stacked), and other elements.

I still like that approach and it is very much a progressive enhancement technique. But as I mentioned earlier, a lot of times I only get a desktop version of the design. In the past, I would still try to write my CSS mobile-first. However, I found that it was very time-consuming to have to make all those decisions at that point in the build.

Several years ago, I switched to a desktop-first build. I would build out the desktop version of the design first. Then I would go back and refactor my CSS adding media queries. I would still structure my CSS for a mobile-first approach but start the build desktop-first. After adopting this approach, I found that my builds went much quicker. And I discovered more happy accidents along the way as I would resize the browser down from the desktop.

What tools do you reach for typically?

This post is part of my attempt to post something every day for a month. I was inspired by Michelle Barker, who recently participated in National Blog Posting Month.

Comments are closed.