FrontEnd North: An in depth look at the event

Having attended FrontEnd North 2016, the dust has now settled, and it's time to document the wonderful knowledge gained from the day, a day packed with FrontEnd goodness.


21 Nov 2016
Jump to article

First, heres a bit about the structure of the day.

There were two half-hour segments at different points in the conference for 10 minute talks on specific topics. A great idea, as it's enough time to show something off and gives a chance to raise awareness of specific technologies that people may not have heard about, but is short enough to not matter too much if it's not relevant to certain people in the audience. I definitely think this is something companies should incorporate and encourage more internally. Here at Quba, we try and run frequent lunch time roundtables and have regular company tea breaks where all updates can be shared and new knowledge imparted.

In terms of subject areas, there was a lot talk about accessibility, which is definitely a subject worth keeping up to date with. Beyond making sure mark-up is completely semantic and adding the correct aria-roles, there's still a lot more that can be done, as was detailed by several speakers.

Anyway, here's some summaries of my favourite talks.

Automated visual testing - Daniel Furze

Dan showed off this awesome little tool called BackstopJS to automate visual regression testing, i.e. testing to see if a page looks any different to how it looked in the previous revision. This is super useful for pinpointing exactly when and where a visual accident occurs, or doesn't occur, if you expect particular elements to change.


As it works based on screenshots of pages, it looks for mismatching pixels. This means it can be used to catch things like fonts not loading correctly, whereas comparing computed CSS might not pick this up. Definitely gonna be adding this to my toolbox. Here's the link to his full article if you're interested.

Developing the front-end of - Robin Whittleton

Before this talk, I was pretty adamant that users browsing without JS enabled deserve whatever terrible experience they get. JS isn't just a tool to do nifty animations anymore, it's become a core part of building functional sites. Rob changed my mind on this though:

People without Javascript don't generally choose to turn it off

He listed some cases:

  • A browser extension could have a JS bug which runs before the site's JS, blocking the site's JS execution entirely (actually seen this before)
  • Users with slow or intermittent connections (e.g. on a train) will probably start using a page before the JS has even downloaded, or the request for the JS could timeout entirely
  • A user might be behind a company firewall which blocks the JS request for whatever reason

His talk went on to explain how a site like has to put user needs first, and can't afford for the site to be inaccessible for particular users. follows full progressive enhancement. That means functionality first, so HTML alone should allow for a functional experience, CSS and JS should just be used to enhance that experience, not enable it.

I'm of the belief that for each project, enthusiasm decreases over time, generally anyway. Translating this to frontend methodology, a graceful degradation approach means solving problems for devices becomes less appealing as device popularity gets older or more specific. Pray you never have to make that cool animation you just did work on an old Blackberry.

Say you start off with a cool design that has funky shapes and gradients and all that jazz. You start by making it work in your usual browser (latest Chrome release), then you test it in IE and realise it doesn't work. So you find a nice polyfill or develop a reasonable fallback to make sure IE users don't lose out too much. After several iterations, you finally get it working on 90% of devices in use today. That last 10% is probably filled with all sorts of random devices, ranging from screen readers to smart watches. Testing and targeting your code for these devices is usually just not worth the time, so you don't bother.

On the flip-side, a progressive enhancement approach provides a functional experience on 99% of devices and feels less hacky. However, getting that extra polish and fanciness for modern browsers feels almost not worth it, as the site is already usable and serves its purpose. You start questioning whether changing that image to use CSS filter so you can do a cool sepia-tone hover effect for 25% of your users is really worth it.

The frontend methodology you choose should follow what goal you're trying to achieve. For, Rob absolutely made the case for progressive enhancement, being one of the UK's most important functional sites. even works without stylesheet support and on just about every device you can think of!


Also some cool data about how mobile usage goes up and desktop usage goes down around Christmas, probably because of everybody visiting family away from their main machines at home.

Refactoring CSS without losing your mind - Harry Roberts

Refactoring CSS is typically a nightmare, and full rewrites are tempting, but often not financially viable. Harry gave some commercially sound advice on this.

Refactoring as you go is the best way to protect against a build-up of technical debt. That is, staying on top of your CSS is really worth it, and bad things happen when you let it slide. When CSS gets messy and doesn't get refactored, it gets increasingly messier, he mentioned the broken windows theory.

A shame.css file is an idea he and Chris Coyier came up with in a podcast. The idea is any code written that you're ashamed of should go in here, instead of dirtying the nice CSS. It makes it easier to tidy up or remove the hacks later on. One point I'd consider here is creating a file like this might encourage people to not stick to the style-guide, or write bad code that they may not have done if they had no other choice than to integrate their CSS with the rest of the codebase. Still, a neat idea worth consideration.

Another idea he had was prefixing refactored code with some name to make it clear about which code is part of the refactor and isn't old code. For example, prefixing classes:

.carousel -> .new-carousel

This way, not only can you tell if code is old or part of the refactor, but you can even target the new classes and show the visual differences using an attribute selector like so:

    border: 3px solid green ;

    border: 3px solid red;

Doing this would put a green border around all elements that have been refactored, and a red border around old elements that still need doing. Pretty cool!

Oh and he gave a little shout-out to all: initial, which changes all properties of a selected element to their defaults, i.e. killing inherited values. Unfortunately, classic Microsoft strikes again.

Functional Javascript, in a nutshell - Katie Fenn

This one gave me Haskell PTSD. Whilst maybe not totally suitable for a front-end conference, it was still pretty cool to listen to. In JS, functions are first-class citizens, which makes it entirely possible to take a functional approach to solving problems client-side and server-side (Node.js).

In short, the general concept of functional programming is to break problem solving down into smaller problems, which you can then go about solving using functions, each with its own specific purpose. Treating functions like singular LEGO blocks, it lends itself to code reuse and readability (so long as you don't dive too deep into the huge callstack that naturally occurs with functional programming).

Two functional programming techniques that can be used in JS are closures and currying. Whilst Katie didn't go into depth on their implementation, she did show off a cool little Mario demo that makes use of these concepts. Anyway, I thought I'd just explain closures, as they're used all the time in the JS world. You've probably used them without realising if you've ever used jQuery.

Closures are a means of making use of the fact that in JS, variables are scoped to their containing functions, not their block. Because of this fact, it allows us to do things like create functions which manipulate another function that they then return.

Consider this code:

function greeter(greeting){  
    var dayOfWeek = new Date().getDay();
    var strWeek = dayOfWeek === 6 || dayOfWeek === 0 ? "weekend" : "week";
    return function(name){
        return `${greeting} ${strWeek}, ${name}`;

This function takes a parameter, which is only used by the function it returns. Because we're returning a function here, calling greeter("hello") won't actually emit any output. What it will do, however, is return a function that was previously manipulated when we passed "hello" to the outer function.

We can use this function like so:

var lovelyGreeter = greeter("Have a good"); // we execute this line on a wednesday  
console.log(lovelyGreeter("Steve")); // outputs "Have a good week, Steve"  
console.log(lovelyGreeter("Tim")); // outputs "Have a good week, Tim"

var terribleGreeter = greeter("I hope you have a terrible"); // excuted on saturday  
console.log(terribleGreeter("Bill")); // "I hope you have a terrible weekend, Bill  

The actual closure occurring here is our inner function makes use of data outside its own scope. greeting and strWeek are both examples of closure because they keep their state and are used by our inner function long after actually being set.

Currying makes use of closures, but that's all I'm saying on currying for now. Maybe I'll write a separate post on it at some point, probably after I've learnt it. If your head hurts from trying to understand functional programming, don't worry, you're in the majority.

Web Components and your Design System - Adam Onishi

Web components are something I've been excited about for a while now. The general idea is you have separate DOMs within the main DOM. They're entirely encapsulated, which means no HTML, CSS or JS can leak in or out of these DOM subsets (proper name is shadow DOM).

Adam showed off how the realisation of web components would almost completely eradicate the need for clever class naming conventions like BEM, because BEM solves the problem of CSS being a leaky global mess of a language, which isn't a problem with web components because it can't leak in or out of the shadow DOM.

Web components bring about a familiar modular ecosystem which is becoming standard everywhere. NPM, gulp and ... deep-breath ... functional programming are all examples of tools that break everything down into smaller, reusable pieces. With web components, it's possible to create components that can be reused not just on one site, but throughout the whole web.

Polymer is a Google built library based on web-components that really makes it all very easy to build your own, and even has a whole catalog of pre-built elements that serve all sorts of purposes that you can just plug in and start using straight away.

I mean just look how cool this is:

      options='{"title": "Distribution of days in 2001Q1"}'
      cols='[{"label": "Month", "type": "string"},{"label": "Days", "type": "number"}]'
      rows='[ ["Jan", 31],["Feb", 28],["Mar", 31],["Apr", 30],["May", 31],["Jun", 30] ]'>


CSS variables: var(–subtitle) - Lea Verou

One of the most impressive talks of the day and the only talk that used live coding for the demos. Native CSS variables are new tech, and therefore you'd expect browser support to be pretty awful, but it's actually not that bad.

currentColor is a nifty little css value that's been around for a while. It takes the place of an actual color value, and inherits the element's current color value. If the element doesn't set color, it's grabbed from the closest parent in the cascade. A quick example setting all paragraph backgrounds to green.

    color: green;
    background: currentColor;

It's essentially a nice way to share colour to other attributes or descendant elements that have colour. currentColor is cool because it's a CSS variable! Now, on to custom CSS variables.

I assume that most people, when hearing about CSS variables, will want to know what they offer that preprocessor variables don't. Fortunately, Lea recognised this too and showed some cool examples of what you can't do with a preprocessor alone.

Here's a quick snippet of what custom CSS variables look like:

    --brand-color: #0f0;
    background: var(--brand-color);

Pretty ugly eh? Well, it was decided that this should be the syntax primarily to avoid conflicting with any existing CSS predecessors, this way, it's possible to use CSS variables alongside preprocessor variables.

One thing that's now only possible with CSS variables, is being able to pass variable data in from the markup or JS. So you can do nifty things like this:

<div style="--gutter: 10px">  
    <div class="item">
    margin-left: var(--gutter);

This could make frontend frameworks that rely on markup data drastically smaller. You could pass a colour into an element which the CSS then uses as a theme colour and applies it to specific parts.

Think of col layouts being 12 times smaller in filesize and passing the col-width through like: style: --col-width: 6. Then in the CSS you can receive this and use calc to work out the col's actual width:

<div class="col" style="--col-width: 6">  
    width: calc((var(--col-width)/12) * 100%);

There, we just saved 5 classes worth of col width percentages. The applications for this sort of thing stretch way beyond just optimising code though. Because native CSS variables are evaluated at browser runtime instead of at preprocessor transpilation, variables that change after render (woah variables that vary, who'd have thought) actually update in real-time with the DOM.


It's worth noting that here I'm changing the variable in dev tools, but it could change based on a media query, or JS could change it whenever (there's an actual native JS API for CSS variables btw). Whilst not all uses were impossible before, it certainly goes a long way in aiding the great cause of DRY CSS.

That being said, implementing a fallback for browsers that don't support custom CSS variables is kinda odd, and appending unit suffixes like px or % isn't possible. Instead, you have to use calc and multiply your variable by 1px or 1%, which feels hacky. I'm looking forward to seeing what creative uses people find for CSS variables in the future, but for now, I'll be waiting until IE/Edge usage has dropped off completely before touching them.

One other person I didn't mention is Charlotte Jackson, who did a really great job of showing off some newer CSS tech like @supports and flexbox. I can't stress enough how awesome flexbox is, so go ahead and give it a try if you haven't made the leap yet. There's an endless amount of great resources out there to help learn it. Also, grid is a thing.

If I had one critique about the event as a whole, it's that there was perhaps a bit too much focus on backendy stuff. Not that I mind, being a frontend and backend dev. Bar some very brief UX mentions, there was hardly anything regarding design, which was a shame. I'd love to hear some talks about bringing design and frontend development closer together, as I think they're treated too separately a lot of the time.

Overall though it was a pretty great event, would FrontEnd North again. 

The hosts/organisers mentioned that FrontEnd North 2017 might be held in Sheffield again next year, so keep an eye out for tickets.

The speakers I referenced: 


If you would like a chat around anything I have written about give me a call on 0114 279 7779. We are always open to questions here at Quba HQ.