I will never forget the look on a contractor's face when he stared at a technically correct, but aesthetically disappointing dormer at our house.

"Everyone can mess around," he said. Referring to the fact that most people can accomplish the basics, but not all master a craft.

In my own industry, there is no specialty that makes me think of these words more than frontend web development.

After all, everyone can hack together HTML and CSS, especially with all these frameworks that allow you to rapidly build user interfaces (UIs).

However, many frontends fail in ways we do not realize when we judge them only by sight.

As someone who has done both frontend and backend for more years than I want to admit (listen, I feel old now), I think high-quality frontend development is harder than most backend work.

And one of the reasons why websites fall flat? That is because many people do not realize just how hard—and different from other programming—frontend development is.

NB. I will not dive deep into technical problems in this article, and will avoid jargon where possible. Many points should also make sense to non-programmers, which is on purpose.

The philosophical difference between frontend and backend

Code for web backends, as well as larger UI-less applications, is, in a way, very simple (but not easy): a large collection of yes/no questions that guide the program down a logical path.

But where backend code relies mostly on logic, a frontend is much more fluid and "it depends", and not necessarily logical at first.

Where a backend needs to gather raw data and ensure it's stored and collected correctly, a frontend needs to display that data in a way that a non-technical user can consume.

In a UI, a page needs not only to look good but also to facilitate human information processing and empower the user to find what they want to know, where they expect to find it.

So suddenly, you have to think about user experience, psychology, language processing, data display prioritization, accessibility, cultural differences, a range of devices, and more.

HTML, for example, is what you use to add context to plain text. If you do that right, both your users and search engine crawlers (and AI bots 😒) will have a better understanding of what each piece of information represents.

CSS will not significantly affect the message of your content, but it is essential for placing information where readers can find it and for presenting it in a readable way.

Lastly, JavaScript adds interactivity. When done right, it allows users to use your site faster or more easily; when done wrong, it can destroy their entire experience.

So in short:

1. Backend is logical, simple, but not easy, and technical.
2. Frontend involves psychology and understanding of how humans interact with data, and is typically non-technical.
3. Even when your message is flawless, your frontend can make or break the user's ability to interact with it.

Another key difference between frontend and backend

If you think about the points from the previous section, you might think: "OK, I've got it, I need to write good HTML and CSS."

And this is where you will run into one of the biggest stumbling blocks of user interfaces: user experience (UX) is contextual; what works for one site might not for another.

I will add more details in the next section, but this is the short of it:

Depending on the importance of information in the current context, you might present the same message in completely different ways on different websites.

Not only may you use different HTML elements for similar data on different sites, but you might also choose to label them differently, or not label them at all.

For example, on a blog, you will want to emphasize your article titles, whereas on a marketing site, those might only be side content, and you would instead focus on unique selling points.

Another example: if you want site visitors to fill out a form, you might add a large heading in view, set the form field to have keyboard focus, and nudge the user toward it. Whereas on a contact page, which already shows phone numbers and email addresses, you might not even draw attention to a contact form.

Accessibility unearths critical flaws

Accessibility and inclusive design are where we really start to notice quality. Think website usability for disabled people, different access technologies, screen sizes (if the user uses a screen), and offering users an experience that matches their preferences.

A site that "looks good" will probably work on the devices the developer owns, be usable with a mouse, and has upper management making happy noises.

But looks are very deceiving in frontend development:

1. The CSS and JavaScript might not work on older browsers.
2. Assets like images might have large file sizes that take too long to load on mobile.
3. Data might be labelled incorrectly, or not at all, making it harder to interpret by a myriad of tools that rely on good HTML (screen readers, crawlers, browser extensions, etc.).
4. The site might not be navigable with a keyboard or voice controls.
5. The interface might not scale correctly with text size when the user zooms the page.
6. The elements are there, but the colors might be too low or too high in contrast for the user.
7. The site might use extensive animations even when the user requests a low-animated interface (triggering motion sickness).

I will add a few notable examples below, but that write-up is by no means exhaustive.

Example 1: Headings and labelled content

There are multiple ways to label content, and several elements and landmarks you could name (label); think forms, lists, important page sections, and more.

I will not dive into the technical details of how to label content, but headings are one of the primary ways to do so.

HTML headings are make-or-break elements. They are landmarks in a page that any user—sighted or otherwise—naturally floats towards to help them find their way on a page.

Headings create what is called the "document outline", which one could compare to a table of contents in a book. These elements need to be present, correct, unique, and displayed in the right order for a page to be navigable.

But if you think that you should label everything to achieve maximum clarity, that is where the previous section rears its head.

Labeling everything is superfluous at best, and a huge strain on screen reader users at worst.

Since screen reader users may use landmark navigation or labels to find their way on a page, excessive labeling will cost them time and add cognitive load because their voiceover software just won't stop talking.

To give a vaguely recognizable comparison for sighted users: Think of food recipe websites, where you first need to trawl through the author's life story before you get to the ingredient list and the step-by-step guide.

Now imagine that every site you visit has the same information overload as a recipe page; that is what excessive labelling can do. And as a sighted user, you can at least scroll past chunks of a page, but that is not an option for everyone.

This is why you need to identify the areas on a page that require quick access, and make only those stand out.

Example 2: Keyboard focus

Not everyone uses a mouse or touchpad to navigate a page; some use only a keyboard.

Not all developers, but many developers I know are mouse users. If you are not primarily a keyboard user, it's easy to forget that sites should also be navigable for these types of input.

Focus management is one of the easiest things to get wrong. For one, did you know that mouse focus and keyboard focus are two separate things? You might click a link with your mouse, and your keyboard could be in a completely different place.

This common scenario will trip up keyboard users:

1. Imagine having a form with rows of input, where the user can add or remove rows by pressing a button.
2. Each row has a delete button within, just after a text input.
3. The user tabs through the interface until their keyboard focus lands on the row delete button.
4. The user clicks the delete button, and the row disappears, including the button their keyboard focus was on.
5. Since the developer did not write code to move the keyboard focus elsewhere—for example, to the input in the next row—it ends up in limbo.

(Bonus points if all delete buttons have identical labels, meaning it's unclear which row they even correspond to.)

Have you ever heard of this problem? The first time I discussed it properly was a few years ago when working with blind accessibility experts.

Example 3: Alternative text for media

A classic accessibility fail is the lack of alternative text for images, as well as subtitles or closed captions for video content.

Alt text for images is more than adding a visual description of the medium; you have to describe what is most important in the current context, much like your regular content. This is one of the reasons why (AI-generated) alt texts can be both very descriptive and still very useless.

Video subtitles are great for offering content translations, and closed captions offer complete dialogue and sound descriptions.

(Fun fact: Did you know that ADHD folks with auditive information processing issues love subtitles, even in their native language?)

Transcripts below a video offer people another way of consuming the message.

But, alternative text is not just great for accessibility: it works for crawlers, and for situations where you cannot load media files.

Despite many of these alternative texts being invisible under typical development conditions, they have a massive impact on page quality.

Wrap-up

You write backend logic for computers and fellow programmers. It's usually a relatively straightforward process that you could encapsulate in a flowchart (the UML kind).

And usually, there should be one—and preferably only one—obvious way to do it.

Frontend code, however, is for humans. These humans are often not as technical as a developer; they probably don't have the same state-of-the-art machines as programmers do, and they might have disabilities that no one on the development team has firsthand experience with.

There is a reason why there are dedicated education tracks in user experience and interface design (UX & UI): there is more to it than "just writing code".

To circle back to the start of this article:

A backend developer can write a frontend that does most of what it is supposed to do, but without proper knowledge, it will never be good enough.

ADHD sidequest: The reasoning above is also why I am allergic to the term "junior full-stack developer". If you know, you know.

If you only judge a website by its visuals, as inexperienced frontend developers and managers may do, then you will miss many pitfalls that make your UI fall flat.

I remember being at uni, and the way people talked about HTML and CSS: everyone was expected to write a working backend, but then just quickly hack together a frontend.

The misconception that frontend is less of a craft than backend is what kills quality, usability, and, for some people, their access to critical information.

So next time someone tells you that frontend is easy, take it with a grain of salt.

Appendix: The special case of APIs

To deviate from the subject for a little sidequest: APIs.

An API is the closest thing a pure backend-focused developer may come to making presentation logic.

While you cannot compare an API to a traditional UI, you can still encounter varying levels of user-friendliness.

Without going into detail, I only want to give you this exercise:

When you write the error handling and documentation for your endpoints, think about how you will help the user help themselves.

Music tip: "You Give REST a Bad Name" by Dylan Beattie.