Karl Hahn Team : Front End Developer Tags : Web Development

Best Practices

Karl Hahn Team : Front End Developer Tags : Web Development

Best practices are usually created in response to features being misused, which creates havoc for other programmers and the company they work for. In fact, most of the innovations or paradigms within the last 40 years have been based around restricting what you do with your technology.

An example is multiple inheritance in C++. It’s now considered bad practice, even though the feature is still available.

Let’s apply this thought to the front-end and see if we can identify some practices that may be harming projects rather than enhancing them.


It’s the worst feature ever. You know it’s going to be misused – I’ve seen a project that contains 8 levels, with dozens of selectors spanning multiple pages. Even when it’s not that bad, it’s still bad. Even two levels can be bad if there are pages of selectors. Source mapping usually points to the parent-selector’s line, so you’ll find yourself scrolling through a few pages to find the real line that you want to edit.

Nested selectors also make it difficult to just scan the file as the final selector is a combination of many lines spread throughout the file. Yet so many people use nesting, thinking that if the feature exists, it must be good to use it – just like multiple inheritance in C++.

File splitting

The next thing I will mention is the desire to split everything into multiple files. As I will explain, if it’s done well, it’s very beneficial. But if it’s done poorly, it will not benefit the project and will instead be a hindrance.

A good way to do this is to split files into components (or widgets or whatever terminology you want to use.) A component may be something like a ‘comment’ or ‘post’, will be used on multiple pages and is visually identifiable when looking at the site. Then you can have a small amount of ‘base’ files, such as ‘mixins’, ‘fonts’ etc.

The poor way is to split files up according to device, resolution, pages or technology-feature. This is why:

Pages: Reusing code for other pages is now an issue.

Resolution / Device: Media queries can have a cascading effect, funnily enough. Queries can affect multiple devices, ratios and resolutions.

Technology-feature: If there are too many of these, you will be playing a game of switch-to-file every few seconds, as usually you will be altering a component, not a whole collection of ‘helpers’.

Breakpoint variables

Another misused practice is to store breakpoints and breakpoint queries in variables. Ideally, when you design widgets and pages, you want a media query to kick in depending on what looks correct for the widget. Some widgets may need to change at 1023, some at 991, some at 1053, etc.

If you store your breakpoints in variables, it means that you’re trying to standardise them to use the same breakpoints. Right from the start, this has become a compromise to the design and usability of the widgets. Now it’s not necessarily incorrect to take this approach, it’s cheap and easy – which is great when you have a tight budget and tight deadlines. But if you’re focusing on quality and developing high-end websites, this will be detrimental to the final product. Be aware of what you’re doing with breakpoints and use them appropriately.


It’s very easy to get caught up in the hype of new features and technology. It’s much harder to realise that an exciting, shiny new feature should be used sparingly, with a strict set of rules, or sometimes not at all.