More Front End Developer Newbie Mistakes

Check out my books on Amazon at https://www.amazon.com/John-Au-Yeung/e/B08FT5NT62

Subscribe to my email list now at http://jauyeung.net/subscribe/

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that newbie front end developers make that we can all avoid.

Relying Too Much on Frameworks

Front end frameworks are great. But we shouldn’t rely too much on it. We should still be able to do things on our own if we aren’t using the frameworks that we’re used to using.

Also, we should only learn frameworks once we’re proficient with plain JavaScript constructs and DOM manipulation.

Otherwise, we don’t know why everything works.

Using Bootstrap For Layout

Bootstrap was great when flexbox and grid were releases or when it wasn’t widely available in browsers.

Now we can use both to create layouts for our pages. Even Bootstrap itself uses flexbox and grid for layouts.

Therefore, we should use flexbox and grid for layouts instead of Bootstrap. Relying on Bootstrap too much doesn’t help us too much. And we’ll forget about the fundamentals.

Instead, we should just stick with the flexbox and grid, which makes the layout very easy.

Putting Our Code All in One Place

JavaScript had modules as a standard for a few years, so there’s no reason to have long scripts anymore.

Instead, we should use modules to divide up our code into manageable pieces.

Also, we shouldn’t have global variables anymore. Instead, we have variables we want to export in modules.

If we want to package everything together into a custom component, we can use the web components API to do that. This way, we can use them anywhere.

Projects created with framework all divide our code into modules. They encourage best practices by dividing things into modules.

Not Optimising Images

Many people don’t have fast Internet connections. Even though many parts of the Earth have broadband, they may not be the best quality.

Therefore, we should make sure that we compress images and shrink them so that their file size won’t be too big.

We can’t have many images that are megabytes in size. They’ll still take a long time to download with slower broadband connections.

To test out the performance on slower connections, we can simulate loading our website or app with a slower connection on the Network tab of the Chrome console.

We can choose from 3G, 4G, and a regular connection.

Using Inline Styles

Inline-styles are bad since they clutter up our page. Instead, we should clean them up by moving them to a CSS file.

This way, we won’t clutter up our page with styles and we can reuse the same style in multiple places.

Not Using Heading Tags for Styling Purposes

Heading tags are great for styling and tell us that they’re headings. Suitable headings have an impact on SEO.

Therefore, we should change headings to h1, h2,…, h6 tags if they’re actually headings.

Photo by Alvan Nee on Unsplash

Not Removing Redundant Styles

Redundant styles are a pain. There are things like having 100% width in block elements like divs that are redundant.

We don’t need to set a width of a div to 100% since the default width is to take 100% of the width of the parent.

Chrome often tells us which styles are redundant so that we can remove them if we see that warning in our console.

Embedding Fonts in a Wrong Way

@font-face is for specifying the font name for fonts that have to be imported.

However, we can also specify the weight of the font within the @font-face block to control the font-weight of the font and keep the same name in both the block for the regular font and the one with a different font-weight.

For instance, instead of writing the following:

@font-face {
  font-family: 'Open Sans';
  src: url('opensans.woff2');
}

@font-face {
  font-family: 'Open Sans Bold';
  font-weight: bold;
  src: url('opensans-bold.woff2');
}

We should write:

@font-face {
  font-family: 'Open Sans';
  src: url('opensans.woff2');
}

@font-face {
  font-family: 'Open Sans';
  src: url('opensans-bold.woff2');
}

Then we can just set the font-weight in our style and then the right font will be picked from the font with the right font-weight or other styles on the list.

For instance, we can use Open Sans as follows:

.foo {
  font-family: 'Open Sans';
  font-weight: bold;
}

Then the browser will pick the Open Sans font face that has font-weight set to bold.

Conclusion

Inline-styles are bad, we should move them to a CSS file so we can reuse them.

Also, we should embed fonts properly by putting the styles in the @font-face block.

Finally, we should think about users with slower connections and optimize our assets.