The easier my life becomes, the higher the barrier to entry

As an industry we love automation. Seriously, we’re obsessed with it! It sometimes feels like there is a new thing each day I step into the office.

That’s not a bad thing, in fact it’s pretty damn awesome. The web industry is fast paced. It’s one of the reasons I fell in love with it. It completely satisfies my short attention span.

A few years ago I could never imagine running a script that would:

  1. Allow me to create organised CSS which could be compiled.
  2. Check for syntax errors in CSS and JavaScript.
  3. Prefix my CSS to support older browsers.
  4. Minify and concatenate my CSS and JavaScript.
  5. Optimise all the images!

And in a blink(ish) of an eye!

All these tools and libraries have made my life easier but the barrier to entry has never been higher. Learning the tools to develop front-ends is now as big a part as learning the front-end languages themselves.

If a tool makes my life easier, I am always up for trying it. There would be nothing better than halving the time I have to work. Who doesn’t like lying in a hammock sipping rum old fashioned.

I am sure most front-end developers share the same view, if not maybe with another preference of drink. The problem is these new tools often require learning new languages or libraries. It’s a double whammy.

New tools are only beneficial if the entire team understands how to use them. It doesn’t matter how useful a tool potentially is, if it doesn’t have the buy in from everyone it’s completely useless.

A magic black box where code is thrown into and mystical things happen is never a solution. Everyone needs to be part of the decision to implement them. Everyone should understand how these tools work.

Share knowledge. We can all learn from and help each other.

How commuting affects my mood

Like many, I commute to work. My average commute time is around 40 minutes each way. Previously it was nearly an hour before changing my work hours to avoid traffic (thanks iWeb!).

Sitting in a car by myself can be the best and worst thing. Often my commute will affect my mood for an entire day.

Like most creatives, web designers are a temperamental and erratic bunch. I’ll often go from elation to devastation in a matter of moments. It’s what makes us good at our jobs. We connect with our feelings – if not a little too much sometimes.

Ideas machine

A benefit of commuting is the ability to think and reflect on the day ahead. Many say sitting on the loo will encourage ideas – commuting is my idea factory. Plus uses less toilet roll. Solutions to both design and technical issues are resolved.


I consume a huge amount of audiobooks and podcasts. When you have 25+ hours a month of free time (or driving time), it allows you to enjoy content you may not otherwise listen to.

I like to think of them as my own personalised radio station. Topics range hugely depending on how I feel. I try to listen to random subjects that I may find interesting – rarely listening to work related podcasts.


This can develop either in the morning or while driving home. Travelling the same repetitive route hundreds of times a year takes a toll. I’ll often go 10 minutes without remembering the last 5 miles of my journey.

I wake up at 6:15am and don’t get home until 5:30pm. It’s a long day! It’s inevitable this will have an affect on my mood. This most noticeably happens in the evenings just as I get home. The overwhelming feeling of exhaustion which is hard to shake off for a few days.


Unfortunately when you’re in a car there is no one to talk to, so your mind talks to itself. Sometimes this becomes the most creative part of the day. Other times it’s spirals into depression.

Depression is rarely spoken about in our industry. It can have a significant impact on the day ahead.

Unfortunately with the combination of tiredness this is more of a common occurrence than I’d like. It can be triggered by the prospect of the work ahead, the previous days work or something completely random.

I’d love to know how others feel while commuting and how they help pass the time. Make sure to tweet me.

NPM and Bower: When to use each

Gulp was my first experience of using package managers. A quick search and you’ll probably notice that NPM and Bower are the popular choices.

Which do you use?

Surprisingly the answer is both. NPM is used for gulp packages – things that do all the crunching such as processing the Sass. Bower is used for website assets – things that will be served to the user such as jQuery.

Why use both NPM and Bower?

There is logic behind the madness. It’s all about how each handle their package dependencies.

If we were to use a carousel sxuch as bxSlider (everyone squirm on the count of three…) it would require jQuery to work. jQuery is therefore a dependency of bxSlider. For bxSlider to work it requires jQuery. So jQuery is a dependency of bxSlider.

Both NPM and Bowers use dependencies but where they store them differs.

How NPM handles dependencies

When installing a package from NPM it will create a folder inside the root of node_modules. Any dependencies will be downloaded inside of that package. If we take the example of gulp-sass, you would have a folder structure like this:


If another module requires gulp-util, it will download that dependency again into it’s own folder. Each package is isolated from one another.

Initially this sounds crazy but it is actually very useful. By each package having their own dependencies and not sharing it stops any conflicts with different versions. No matter what you install, it will work.

The nodes_module folder can get very large. But since we only use NPM for gulp packages we don’t care.

How Bower handles dependencies

When installing a package with Bower it will download all the dependencies to the root folder of bower_components. Taking the earlier example of bxSlider, it would give you the following folder structure:


Unlike NPM, Bower installs dependencies in the root folder. If we then decide to install another package that relies on jQuery it will use the pre-existing package.

Bower is more prone to conflicts with packages requiring different version of other packages. This may feel annoying but it’s very useful, who wants 3 versions of jQuery on one site?

Bower works much more like the JavaScript would on a website, using only one version of each script. This is why Bower lends itself better for assets that will be used on the website.

I spent an hour choosing a class name

There, I said it. It’s not procrastination, it’s planning and there is a big difference!

Modal, flag, media block, popup, drawer, overlay, suggestive search, breadcrumb, follow us icons, pagination, sort by, list item, facets, filters, widgets, newsletter, title, heading, social share, nav, nav dropdown, buttons, forms, inline forms, banners, carousels, tabs, accordions, tabs to accordions, toggles. I could go on…

What’s in a name?

Well actually a lot!

The beauty of CSS is it’s simplicity but it’s also open to interpretation. This is great for creativity, terrible for large projects.

Planning the structure and naming conventions of your CSS is critical for a successful project. Remembering to document everything as you go along. The goal is for anyone to be able to jump onto a project and understand what’s happening.

How to name classes

Here are a few pointers I use when naming my CSS classes.

1. A class should have one function.

Don’t over complicate things. Classes should only perform one task. As well as simplifying the naming process it creates a reusable style that can be applied anywhere. It’s okay to use multiple classes on a single HTML element. The goal is to create flexible, lean and usable code; not attractive code.

2. Name what it’s doing, not what it contains.

The same layouts or styles could be applied to lots of different content. Name your classes after what they do and not what they contain. We don’t want to be duplicating CSS down the road or even worse, giving things the wrong classes.

3. Use BEM – Block Element Modifier.

BEM is a naming convention that uses double underscores and dashes. BEM allows you to see the relationship between styles without delving into the CSS. Double underscore represents a reliance on part of the name that prepends it. A double dash distinguishes it as a modifier of the default functionality.

A good example is an article that contains a title and content with some being sticky. Here is an example of BEM in use:

Last November I presented a talk about BEM at Staffs Web Meetup. Harry Roberts also wrote an introduction to BEM on his blog.

4. Use namespaces

CSS doesn’t only apply aesthetic styles but also JavaScript or temporary states. Prepending your classes with js-, is-, has- or u- makes the function of that selector much more transparent. Again Harry Roberts wrote a great article on using namespaces.

5. A partner in crime.

There is nothing better than talking things over with a colleague. This will help focus your ideas while getting the perspective from someone who may eventually work on the code you’re writing.


I spent an hour deciding a class name and I’ll do it again.

The real CSS has landed

It’s took a while, but it finally feels like CSS has matured to what it originally promised.

Gone are the days of clearfixes and floats, let alone transparent PNG fixes and weird browser specific selectors! Remember having to use a * at the beginning of selectors to target IE6 and below? If you’re in a reminiscent mood, here are some more.

We often hear the phrase ‘good old days’. I am glad the good old days are behind us! Good riddance! I’m not a religious person, so to reference something from the Bible it has to be good! Ecclesiastes 7:10:

Do not say, “Why were the old days better than these?” For it is not wise to ask such questions.

Hello to a new era of CSS. It finally feels like it caters for our needs. The introduction of CSS calc, flexbox, nth child, just to name a few, are revealing the power of CSS and flexible layouts.

Responsive web design is what the web should have always been. Instead of mimicking other industries such as print, we’re now able to stand proud on our own two feet and innovate for a better web.

Internet Explorer is no longer a special case where we have to support several versions. Thanks to the introduction of other options, Internet Explorer’s majority has diluted down to a mediocre 12%, and that’s only if you include IE7 and IE8.

We often moan about the number of browsers on the market but it’s created a level playing field. For the most part they all behave the same. It’s forced browsers to keep up-to-date and include the new CSS features we’ve all been craving for. We can now focus on creating a better browsing experience instead of supporting quirky browsers.

The real web’s pretty awesome. I love real CSS.

CSS calc is more supported than media queries

Calc is awesome.

If you’ve not come across it in CSS, it allows you to do calculations. The big benefit is you can calculate across different units. It’s handy when building responsive websites. There are often times you need to calculate things like 20% – 1rem, well now you can! Here is an example:

The best bit is the support. Calc has better support than media queries, yes you read that right. Every browser including back to IE9 support it apart from Opera Mini.

Using SASS variables in Calc

You might try to include SASS variables inside calc and find they don’t work. The output in the CSS file with print exactly what was inside the calc function. If you include one it will print the variable name, not the value. After some digging I found you can wrap your variables so they work like anywhere else. It feels a little hacky but hey, it works!

Just one word of caution

When using it with pre-processors such as SASS or LESS you may start getting calc happy. Keep in mind if you’re calculating two values with the same units you can us your pre-processor. This will create cleaner and faster CSS. Just use calc when calculating two values with different units.

UPDATED 03/07/2015: Added using SASS variables inside calc

Sometimes you just need to write

To procrastinate as much as I have is a skill. It has to be, else I have a big personality deficiency. Starting a blog is hard, especially when you work in the industry and you’re a designer. My fixation on look causes me to down tools and run for the nearest dark closet.

Recently Phil Wylie said to me:

Sometimes you just need to write.

I’ve always had a fear of not knowing what to write about. I have lots of experience in the web industry but there is always a niggle that someone else has covered that topic better than I could.

I recently listened to Unfinished Business, a podcast hosted by Andy Clarke. On this particular episode Jeremy Keith spoke about writing a blog for your future self and not worrying about what others think.

The web industry is a fast paced place (say that after a few drinks). We’re continuously learning new things, writing them down serves three purposes:

  1. It helps us focus our thoughts.
  2. To help remember how to do things.
  3. It acts as a reference for our future selves.

I think setting goals are important. They give focus and targets to strive for. So here are my goals for this website:

  1. To express my personal opinions on topics.
  2. To experiment, learn and develop my skills.
  3. A reference for myself.
  4. A place to focus my thoughts, allowing me to think more rationally.
  5. To enable me to write more.

Sometimes you just need to write, so hello! I’m Dave and this is me writing.