How to achieve maintainable front-end code
Nobody likes messy HTML that makes it a nightmare to make future changes. For any project to be enjoyable to work on, you need to ensure that it’s done right. Jumping to and from old projects as I do on a daily basis, you get a much clearer view and appreciation of how your code has improved in terms of structure and maintainability in comparison.
In this post I’m going to outline the steps I try and take in each new project to ensure the code is clean, semantic and manageable.
You often see the term “semantic html” cropping up throughout the web world, but a lot of people don’t really understand what it actually is or why it’s important. Semantics is in my opinion is one of, if not the, most important thing to bear in mind when coding up any page.
So what is “semantic HTML"? In short, semantic HTML is HTML that has meaning. Your elements and classes should describe the content in a meaningful way. Base classes should be short and sweet to describe the content, with additional classes describing how/why it differs from the base.
An important tip is to make use of named elements. Elements such as header, footer, article and section are a much better alternative than their
<div class=“header/footer/article/section”></div> counterparts.
<div> has no meaning, it’s just an un-styled block element. Named elements are much more meaningful to the content, and can reduce the need for additional classes as you can directly reference the element. This also reduces code bloat, which is always what you want to achieve.
It’s also important to remember that named elements aren’t always literal. For instance, header and footer don’t just have to be used at the top and bottom of your layout as literal header/footer containers. These elements can also be used inside other elements such as an article to contain information at the top of the article such as title, author, time posted, etc. As long as they provide meaning, they are semantically correct.
As I mentioned previously, bloated HTML is bad and should be avoided. A good practise for this is to offload styling elements to pseudo elements. So any element that is only there for small bits of styling should be moved into a :before/:after pseudo element for the parent.
CSS frameworks are notoriously bad for this as they usually require you to add multiple non-semantic classes for you to achieve the actual styling you want. So how do you avoid this? A CSS pre-processor such as LESS or SASS which allows you to pull in framework styling within a semantic CSS rule decided by you, to suit your specific needs.
I hope I’ve helped your understanding of semantics and given you enough tips to effectively improve your development on the front-end. I’m sure there’s plenty I’ve missed, as there’s always more ways to improve readability and maintainability, which you’ll appreciate much more when you return to the project.
If there’s anything major that I’ve missed, let me know and I’ll amend the post!