You’re all invited to Harry’s bar 🍻 — The best front-end insights from Harry Roberts' AMA

Harry Roberts, the super-rad FED man 😄 — the unofficial nick that has been going around in the office for a while — graced us by hosting a delightful AMA, filled with awesome insights and opinions, touching upon various Front-end perf. and related topics.

We’ve got ten of the best questions here, and their answers, which we think all front-end aficionados should absolutely read.

Here is a link to the AMA page with all of the answers and questions in their pure unabridged form if that is how you prefer them!

Did you know of Harry’s applaudable home bar?

What are a few of the simple, yet not very well known “front-end performance” tricks?

I love this question! I’m gonna focus on simple.

  1. Simply move your CSS’ link elements to as close to the top of the HTML document as you can. Seriously, it can make a difference. I did an audit for a company once and their CSS was linked on like line 81 of their HTML; this meant that touch icons, Facebook/Twitter card images, plugins’ JS, etc. were all being requested before their render-blocking CSS was. By moving the CSS up to line ~5 we managed to improve render time by a good half second.

  2. Don’t put scripts at the bottom any more: make use of async and defer attributes

  3. Make use of resource hints to tell the browser to prioritise things out of regular order (or for subsequent navigation).

What are the things to be kept in mind when refactoring CSS?

  1. Try and avoid refactoring CSS whilst it’s still inside the codebase, otherwise you’re jut going to end up leaning on stale/legacy code. Refactor/rewrite/rebuild things out in Codepen (or similar) so that you’re starting with a completely clean slate, and then move things back into the codebase from there.

  2. Make sure you signal/highlight what has been refactored—you don’t want people redoing the stuff you’ve redone!

  3. Refactor the things with most business value first.

  4. Don’t refactor anything with a large surface area: refactor small things that only touch a small amount of the project.

Get all of this in long form here: :)

How does one gain a “complete” knowledge of CSS?

  1. Read specs.

  2. Focus on one thing at once.

  3. Find the people who specialise in areas the most (e.g. Hugo Giraudel for Sass, Rachel Andrew for grid, Ana Tudor for math, Sara Soueidan for SVG, Paul Lewis for rendering performance, Rachel Nabors for animation, Lea Verou for basically everything else).

  4. Take things apart. Seen something cool/intriguing? Take it apart and then put it back together, but better. Learn by (un)doing.

When should !important be used?

!important: 3 seconds to type, 3 years to remove.

Use important proactively: apply it to Utility classes, e.g.:

.u-text-center {
  text-align: center !important;

We’d literally never want this class to do anything other than text-align: center; so we force it to always win by using !important.

Never use !important in anger. Don’t use it to get out of specificity wars. Instead, hack the specificity of your existing selectors around.

I’ve written and spoken quite a lot about !important.

How do you deal with the horrors of JavaScript/CMS plugins injecting their nasty markup into your projects?

Usually I just Deal With It™—there’s probably something more important to be worrying about. However, if the HTML is littered with IDs that we can’t get rid of, opt to use an attribute selector to style it instead (e.g. [id="foo"] {} instead of #foo {} because then at least we’re not using an ID’s worth of specificity.

What are your opinions on utilising data attributes for styling? (as done in this codepen)

The purist in me doesn’t like it. Data attributes, as per the spec, are:

to store custom data private to the page or application.

They’re a store, not a hook.

However, I’m starting to soften that stance a little. If you want to style something because it contains certain data, it might be a good idea. However, using them where a class could/should have sufficed is probably not the right way to go.

What are your opinions on frameworks like Bootstrap, and Foundation?

Firstly, I want to make a rather pedantic point that Bootstrap, Foundation, etc. are not frameworks. They’re toolkits. That’s not a criticism, but it’s important to note that, where a framework offers guidance and standards, toolkits like these go a step further and offer bits of styled/opinionated UI.

The comparison I make is that Symfony is a PHP framework, whereas WordPress is a blogging platform written in PHP. The difference there is the difference between a framework in its truest sense, and a UI toolkit like Bootstrap, Foundation, etc.

For more opinions like these:

Do you think it is necessary to have front-end design and front-end development run in parallel?

I think that it’s usually impractical to do both in parallel, but getting close to parallel is a huge advantage. I don’t necessarily advocate designing in the browser, but I definitely share my buddy Dan’s sentiment of decide in the browser.

Get into the browser as soon as you can, whether you’re the designer and FED on the project, or even if those are two separate people. Having the design phase then the build phase only sets everyone up for disappointment.

Is the dream of a truly clean, tidy, maintainable code base really achievable?

Until every developer on the team is a clone of a very talented developer, then it’s not realistic to have a completely perfect codebase. As soon as we recognise and acknowledge that, we can start focusing on good enough, and that’s where we can make value: It’s not perfect, but we can work with it; we have tech debt, but we have a plan to repay it; it could be neater, but it’s not slowing us down.

Whenever I write or get on stage, I’m talking principles and ideals and theory—even applying them word for word isn’t enough when you’re working in the real world. They exist to make life easier, not perfect.

What is your pick — Agencies or Products?

Each have their own merits, but I absolutely prefer products. Agencies give you diversity and variety, but there is little incentive from anyone (clients, managers, us) to focus on code quality.

The client just wants it working for as cheaply as possible; your manager can’t sell ‘code quality’ like they can sell social media integrations; developers will be on a different project in eight weeks anyway.

When you work for a product, however, the tables are turned! You’re both the client and the developer, so it is absolutely in your interests to write better quality code. You’re going to be looking after this in two years time, so do your future-self favour and do a good job. As soon as you hit Save, you’re leaving legacy—make sure it’s worthy.

You can find the full AMA here.