Category Archives: Industry

My preferred Front-end development process

Naga IT Services
Filed under: Industry, Process

I was looking at bits and pieces of the Front-end work I’ve been doing at Praekelt, and I decided to gather them together in one place. I call it my preferred Front-end development process because I’m trying to be more of a grown-up these days and accept compromise on some of these points :).

(Also around as a Gist)

Front-end development process

I build web sites so that people can access them quickly and easily, regardless of the device they’re using, the type of connection they are on, or any disabilities they have. That means I build things with Progressive Enhancement.

The PE TL;DR is: a basic, functional, experience is delivered to everyone. JavaScript is not required for any key functionality (because all your users are non-JS while they’re downloading your JS).

Progressive Enhancement

PE is an approach to web development that aims to deliver the best possible experience to the widest possible audience, by putting the user first. It works by layering on the content (HTML), presentation (CSS), and behaviour (JavaScript) bit by bit. It means using feature detection rather than device detection.

I do feature tests in JavaScript (possibly using a library like Modernizr) to load in CSS and JS enhancements that match the capabilities of the browser. Different browsers will be served different experiences: they will be consistent and may be quite similar, but will not be identical.

Browser Support

I treat browser support as a continuum rather than a list of what is and what isn’t supported. Every device with a browser is supported, but the target audience will guide where most development time will be spent on optimisation. Rather than grading browsers, each component (in HTML, CSS, and JS) of a site is graded.

Internet Explorer is notoriously difficult. The amount of time spent optimising for various versions of IE should be determined by your user base.

Performance and Accessibility

I care about front-end performance and accessibility, so I run regular perfomance and accessibility audits using tools like Google’s PageSpeed Insights, WebPageTest, and pa11y.

I prefer fewer, larger, files over many, smaller, ones, because latency is more of a constraining factor than bandwidth. I make my files as small as they can be, and serve all content using gzip.

Images are one of the biggest performance problems, so I follow Lara Hogan’s advice. I use CSS instead of images where I can, choose the right image format, and make sure that all images are optimised. Depending on the use case, I use the picture element (with the Picturefill polyfill).


I make sure that I provide fallbacks for fancier features, like providing an rgb fallback whenever rgba is used.

I keep all my CSS in a few, minified, external CSS files. I don’t use inline style blocks (except for fancy techniques like Critical CSS) or write inline CSS.

I write my CSS like SMACSS. CSS is organised into: Base; Layout; lots of Modules; States. I keep selector nesting shallow, and never use IDs for styling.

I make sites Responsive by default as a Future Friendly measure.


I write unobtrusive, (harshly) hinted, JS. I keep all my JS in a few, minified, external JS files. I don’t use inline script blocks (except for small, minified, things that must be in the document head, like Scott Jehl’s eCSSential for asynchronously loading stylesheets) or write inline JS. I only include jQuery when really necessary, preferring vanilla JavaScript code and micro-frameworks.

I Cut the Mustard (test the browser’s capabilites using a small bit of JS) and serve less capable browsers just the core, lighter and faster, experience, rather than sending them lots of code they will struggle to run.

Deciding in the the browser

I prefer to move into HTML, CSS, and JS sooner rather than later so that I can test in browsers, on real devices, to make better decisions. I build Front-end Style Guides in an Atomic Design-like style (like Pattern Lab) with pieces that combine to become the site / app.

Mobile stats and things

Naga IT Services
Filed under: Industry

Every quarter ScientiaMobile publishes a Mobile Overview Report, which always has some interesting stats. I look through it because I want to be aware of what kind of devices people over the world are using, and I want to keep the device lab up to date. Here are a few highlights that caught my eye.

Feature phone browsing is (still) about 12% of mobile use

The split between form factors in Africa is 12% feature phone, 62% smartphone, and 26% tablet. Feature phone browsing on other continents is in the single digits, and rapidly dwindling.

This is important to keep in mind because feature phones don’t have great support for fancy CSS and JS. In fact, they don’t have great support for older CSS and JS.

There is no fold

Scrolling is a natural, easy, action on smartphones. People are more likely to scroll if a page takes more than a few seconds to load. Luke W has more great stats and research on this.

This makes me wonder about the many sites that have a large image (or auto-playing video) in the header: how many people scroll right past it (at least on the first visit)?

Android is huge

iOS takes up 33% of the global market (with Android taking up most of the rest), but the picture closer to home is a bit different. Africa has only 8% iOS (Europe and North America are at 32% and 47%, respectively), 8% on Windows phone (more than the rest of the world, but dropping), a staggering 79% Android, and 5% for the rest.

In terms of Android versions across the world, various flavours of 4 take up most of the market, with older version taking up only single digits.

For me, this means updating the device lab with another Android phone that fits the specs of popular locals devices: cheap, fairly low power, but running a version of Android 4 (one of Vodafone’s Smart 4 devices or one of the MTN Steppa family).

Busy, busy, busy!

Naga IT Services
Filed under: Industry, Projects

The past few months have been a little bit busy. Lots of exciting things have been happening, and work has been interesting, but that hasn’t left a lot of time for reading or writing.

Cape Town Front-end developers

At the start of July the CTFEDs meetup group had a great talk from Deb Butler of the Startum Project: “I Know More Than You” – Said Every Client Ever. It was a frank and open talk about the trials and tribulations of being a freelancer in the web development business, and I really enjoyed it.

We also finally got around to starting our website: Yes, it is more than a little ironic that people who make websites have taken ages to make a website for themselves :). Behind the scenes the site is hosted on GitHub Pages, and is powered by Jekyll. You can view the source code for the site on our GitHub repository.

Our next event is a little different: we’re running a workshop as part of the Open Design festival. The festival’s theme is Design is for Tomorrow, so we’re inviting people to come and get help making their sites more Future Friendly. Join us!


At the end of July I was scheduled to give a talk about the hamburger icon, but due to a scheduling snafu at the venue it had to be postponed. It seems like it might be the end of this month instead: I am ready to rant!

At the start of August, I gave a short talk at Friends of Design about #fedlyfe. I talked about how I got into Front-end development, what the jobs I’ve had have been like (in terms of team, roles, culture, …).


Then, just last weekend, me and a handful of fine friends ran a Railsbridge at the University Cape Town, for the Women in Computer Science group. You can read more about the event on our site.


Maybe I need a holiday! :)

The CSS bits of Progressive Enhancement

Naga IT Services
Filed under: Industry, Process

At work the other day we were talking about Progressive Enhancement and feature phones, particularly in terms of CSS. The feature phones part of the chat led me to write up a short Dos and Don’ts of Feature phone design (written for designers more than developers). The PE part of the chat made me scribble up the following pictures.

Every web page looks like this. A base of HTML, with CSS layered on top, and JS layered on top of that. It’s a triangle because the balance should mostly be like that: lots of HTML, quite a lot of CSS, and as little JavaScript as possible.

Practically speaking, we chop things up a bit more than this, though.

First we load in a small file of simple CSS. Then we do some PE fancy magic testing stuff and load in Fancy CSS for fancy browsers.

Actually, though, even the fancy CSS file is splitty too. Inside the fancy CSS file we do more little tests and give fancier browsers fancier styles.

Technical details

The initial split between basic and fancy CSS files is done using a media query on a link element.

The basic CSS is loaded like this:

<link rel="stylesheet" href="/css/style.css">

All browsers get this stylesheet (and it contains simple CSS rules that all browsers will understand). The fancy CSS should be loaded like this:

<link rel="stylesheet" media="screen and (min-width: 20em)" href="/css/enhanced.css">

Since it’s qualified with a media query, it should be the case that only browsers that understand that media query (goodbye old Internet Explorer, and many older phones) load that stylesheet. However, Scott Jehl’s tests have shown that this isn’t the case: browsers are greedy and download all the stylesheets, even ones they will never use!

That’s not so great. Ideally we’d like to improve Front-end performance by using Filament Group’s loadCSS to asynchronously load our enhanced stylesheet (so that it doesn’t block page render), but that would mean everyone downloads every stylesheet. Instead we use Scott Jehl’s eCSSential. This lets us load the CSS file asynchronously (yay, performance!), and use matchMedia to test for (min-width: 20em) with JavaScript. Testing with matchMedia in JavaScript rather than than a media query on a link element works: browsers only download the stylesheets they need. (Of course, we also provide a no JavaScript fallback in a <noscript> tag, in case something goes wrong somewhere.)

You can see an example of this in action on my work in progress project, fufu (A future friendly front-end style guide that even caters for feature phones).

Gotcha: older Androids

The use of matchMedia has me a bit conflicted. Looking at matchMedia on, we see that this means that Android versions less than 3 and Opera Mini users won’t get the enhanced stylesheet. If we went the loadCSS route, some Android 2.* users would get the enhanced styles (which their browsers are capable on displaying), but we increase data costs for all users, because everyone loads all the stylesheets.