10 Common Frontend Mistakes And How To Avoid Them (Update)

In the perfect world, there would be at least one back-end and one front-end developer on a project. In the real world, though, the front-end guy is often missing. There are a number of things that might lead to the lack of a front-end developer on a project, but we’re not going to talk about those in this article – in general, most of the reasons are strictly related to budgetary constraints. This article will be especially helpful for the back-end developers who sometimes find themselves in the above situation and have to take on some of the front-end developer’s responsibilities.

Not Optimising Images

It is a very common frontend mistake. When you test the result of your work in a local environment, where everything “downloads” instantly, it’s very easy to forget about the bandwidth usage and make the download time of your website very long. I can’t count how many items I’ve seen embedded pictures that weigh 4 MB and were displayed as 200 x 150px thumbnails, which is a really big waste of bandwidth.

You should check the size and eventually optimise every image you get from people you work with (unless you’re sure that they have done it before passing it to you). You should consider establishing a stable workflow for optimising images in order not to spend too much time doing it.

Tools for image optimisation that I can recommend are ImageOptim for .jpg and .png and SVGO (Which stands for SVG Optimiser) for .svg. ImageOptim offers a GUI by default, but there’s also a CLI available. SVGO has the opposite approach – a CLI by default, but there’s a GUI available if you feel more comfortable with it. I strongly recommend using CLI versions of both, since it’s undoubtedly the fastest way.

Ignoring Mobile Media Queries

Back-end developers are not used to checking whether changes applied by them also work on mobiles, because in 99 percent of cases, they really don’t have to. Most back-end developers apply a change, test it on a desktop breakpoint then happily tick the task as done.

If you always forget about testing your changes on mobile devices, you might consider adopting a mobile-first approach to always start your frontend work from mobiles.

Using Inline Styles

Using inline styles is easy. You don’t have to care about the specificity in CSS, and you can totally ignore the existing selectors, because you will override those styles unless the selectors have some !important inside. Guess what – in a vast majority of cases using an inline style is a poor idea. The point of .css files is to separate the styling from the content (which is delivered in .html files) and you break this separation by using inline styles.

Let’s imagine a situation in which a developer is asked to change the colour of all the links linking to job ads to orange. We could use a selector in CSS like this:

but then we’ll affect all the links instead of only those linking to job offers. We can’t do that. The other fastest way is to use inline styles so we’ll add an inline style to every <a> tag that points to /job-offer/foo. We change this:

to this:

Now imagine that our designer tells us “Hey dude, I changed my mind – remember those job ad links? Let’s make them blue now.” Now you’re in trouble, because you’ll have to go through every link again and change orange to blue, which will take quite a bit of time.

Instead of using inline styles we should create a class, for example .link-job-offer:

then apply the class to every link that points to job ad so the line with color: blue will be the only line that controls the colour of every link that points to the job ad. Isn’t it great for maintenance?

Using Inadequate Heading Tags for Styling Purposes

The other frontend mistake that I regularly see is using heading tags (h1, h2, h3 and so on) just because they’re already styled and have a desirable look. Using suitable headings for a given type of content has a huge impact on SEO, so we definitely need to care about them, and there are many pitfalls that you might want to look out for.

Let’s use our brand’s design to give you an example of such a pitfall:

Can you see the "Promoted” caption in the background below job ads? Let’s imagine that we start coding this section, and we have already styled our h1 tag to look exactly as “Promoted”. So should we use h1 for it? The answer is NO. The title that describes this section is “Promoted offers” and the big piece of text in the background that reads “Promoted” is only a decoration which can fit into the usual div.

Now, the question is how to make use of the h1 that we have already styled. What I recommend here is adding extra class selectors to every heading selector. You can turn this:

into this:

Now you can use .h1 and .h2 classes to make things look like headings without interfering with SEO.

Using Styling Classes as Hooks for JavaScript

Just like in CSS, we can select elements in JavaScript, and it’s good to separate the classes that are needed for your CSS from classes that are needed for your JavaScript. Why? Let’s imagine that we have a button that says “Sign up for the newsletter”, and we want to show the user a modal with a newsletter form after they click on it. The HTML could look like this:

in CSS:

Now we’re going to write some JavaScript to tell the browser to show a newsletter modal after the button is clicked:

Everything works fine, but imagine that two weeks later we add three more buttons to our website, and all of them should look like just like the one for the newsletter. It would be strange to use the .btn--newsletter class for those new buttons, since they have nothing to do with the newsletter. The recommended course of action in such case would be to refactor this:

into this:

Then apply .btn--green to all the buttons. Now guess what will happen to the newsletter button.

If you think that the newsletter modal will no longer show up after the newsletter button is clicked, you’re 100 percent right. How can we fix that and prevent similar situations in the future?

Use separate classes for JavaScript hooks. Let’s add a .js-btn-newsletter class to the newsletter button, and this will be the one we’ll use for the JavaScript hook.

Now everybody knows which classes are responsible for styling and which are for JavaScript hooks, owing to the js- prefix.

Not Removing Redundant Styles

Sometimes, I have the opportunity to do a code review for newbie developers, and an error they make quite often is leaving redundant code that does nothing.

I can point out three typical frontend mistakes here.

1. Having display: block in selectors that have a float property other than none (if we float an element in any direction it becomes block)

2. Having width: 100% on a block element (blocks take 100% width by default)

3. Overriding a property in a single selector

Embedding Fonts in a Wrong Way

I noticed that many developers tend to misunderstand how @font-face should be used. They do not specify font-weight and font-style in their @font-face declarations and control those properties via the font-family property.

Let’s analyse a case with this particular error:

This code assigns Averta to the elements by adding font-family: 'Averta-Regular' to their CSS selectors, but if we add font-family: 700 either nothing will happen, or we will see false boldness that came about as a result of processing a regular font by the browser. The only way to achieve displaying Averta in bold is having font-family: 'Averta-Bold' in the styles for the given element.

We can easily fix that, just make the font-family’s value the same in @font-face declarations and add adequate font-weight properties:

Now we can easily use this font just like the usual ones:

We can do the same with font-style if we have separate font files for different styles.

Not Abstracting Elements

Abstracting elements in CSS is the process of turning child elements into standalone elements. Below you can see the newsletter section taken from our company’s website.

In Netguru, we use BEM so our HTML could look like this:

Let’s imagine that a week later, we have to place a heading identical to the one above in another section on another page. The proper approach to this would be making .newsletter__title a standalone element, so we’ll move the CSS properties from .newsletter__title into e. g. .section-title. Eventually, the HTML for our newsletter will look as follows:

We’ll be able to use the .section-title module wherever we want, even outside the .newsletter module.

We can make our workflow better by predicting those situations and abstracting elements in advance. When to abstract? Every time you think that a child element will be used outside its parent in the future – abstract it.

Not benefitting from the Goodness of Flexbox or CSS Grid

Flexbox solves countless problems, and it’s pretty easy to benefit from it (unless you have to support IE9 or lower). I often see developers struggling with floats and inline-blocks, while they could use flexbox or the CSS grid property and do the same things five times faster, cleaner and easier.

The first time you use it, flexbox can be confusing, and this is probably the reason that some people try hard not to learn it, but trust me – it’s super worth it. Just find any interactive tutorial (there is plenty of them out there), give it no more than 3-4 hours, and you will be a flexbox pro. I would recommend Flexbox Froggy – it’s sheer fun to go through it.

If you’re not sure yet, make sure you check out Solved by Flexbox, a project created by Philip Walton, where he explains what can be achieved with flexbox that used to be impossible/hard to do without.

Uppercasing Things in HTML

When we have to code a section’s title e. g. “JOB ADS” we have two options to make it uppercase. The first of them is to write it exactly like this in the HTML:

In most cases, it’s the wrong way. Our second option is to use the text-transform CSS property:

Why was the first option wrong? The division between HTML and CSS is about the separation of the document structure and the presentation layer. This title’s being uppercase belongs to the presentation layer, so we should definitely do this in CSS.

Still, we have to remember that there are cases where uppercase words in HTML are the right way to go, for example when you quote someone shouting something.

Summary

The most popular frontend mistakes result from carelessness.

Programmers tend to finish their tasks as quick as possible, but if they don’t think about the future and prepare unscalable solutions, they are going to pay for it later by spending time on refactors that cost money.

All of the frontend mistakes presented above are very common and could easily be solved by applying the techniques from this article. If you’re an experienced front-end developer form a good web development company and already know these tricks, you can send the article to the back-end developers working at your company. I’m quite sure they sometimes need to change something in the front-end, and it would save them a lot of time if they could do it by themselves.