Cast your mind back to 2012

A time when…

• Responsive web design was taking off.

• Grid systems were all the rage.

• Bootstrap and NPM had only been out for a year.

• One-pagers and parallax were cool.

• The iPhone 4S was in the shops.

• JQuery was an industry standard.

• Everyone wanted an app.

• 4G data was still a year away.

• and we built the first Etch site.

Back to the future!

It’s 5 years later and we’ve just rebuilt our site using new technologies, whilst following the latest standards.

When looking back at the old site to compare like-for-like, it’s interesting to see how much has changed.

But does “new” mean it’s better, or just different?

Getting set up to develop

The project repo is still controlled with git, but we’ve moved from Bitbucket to Github. Setting up the project used to be a much more manual process than it is now.

In 2012 you’d pull down the repo, set up the git submodules, create a virtual host, create some writable directories for the PHP templates, create a mysql database, set up the wordpress config, import the database dump, fire up grunt and finally see the website.

In 2018 you run yarn && yarn run develop.

Dependencies

Everybody is using npm now right? Back in 2012, we barely had a package manager. We used a tiny sliver of npm to pull in Grunt. We manually installed everything else.

We had such a small number of dependencies I can list them in writing:

• PHP
• Grunt
• Twig
• Less
• FastClick
• Webfontloader
• jQuery 1.8.3 with: pep, zoom, swipe, animated
• Modernizr

Plugins were “installed” by copying the minified code into a plugins.js file. Now, everything is pulled in from npm and imported into the build using ES6 import syntax.

The new site has over 1200 folders in the node_modules directory. Some of these are to help us build the site, some are to help run it. There’s a lot more JavaScript and zero PHP.

Build

The old site used Grunt to compile the Less and uglify the JS. It had a simple, 65 line, handwritten Grunt config that ran watch, less, and uglify.

In 2018, Grunt has all but ceased development and Webpack is the name of the game. We’ve got an awesome Webpack build that does far too many clever things for me to list.

Server side rendering

In the 5 years between versions of our site, server side rendering was normal, then nobody did it, and now it’s back again! We’ve seen the rise and fall of pure JS rendered client side apps.

Our old site rendered itself on the server using PHP and Twig templates. Our new site runs a Node Express server, then uses react-jobs to help pre-render the app on the server before it’s rehydrated on the client into a full SPA.

Both of them work without JavaScript* :)

*in the browser

Data

There’s not a huge amount of data on either of the sites, old and new. We use data objects to store repeated information about people and projects. The old site used PHP associative arrays, whereas the new one uses JS objects.

Not much has changed here, only the programming language!

Templating and components

Component driven development is everywhere in 2018. Component libraries are a common occurrence in product companies. Everyone has their own version of Bootstrap specific to their organisation. React, Vue, and Angular are all based around the concept of reusable components. CSS styling is component focused. We love components!

The old Etch site used an early form of component driven development. We had various types of “content block” available as Twig templates that could be stuffed with images or text and set to different sizes in our grid.

The new site uses React to create our components in a variety of shapes and sizes. We use Brad Frost’s Atomic Design methodology to organise our code into Atoms, Molecules, Organisms, Templates and Pages.

CSS

In 2012, CSS compilers were just taking off in popularity. We were pretty sold on LessCSS and used SMACSS style naming and organisation conventions.

In 2018, we’ve been using Sass and the BEM naming convention for a few years now. We organise our CSS files by components rather than layout/module/state/theme

We had 15 less files, now we have over 50, but everything is so much easier to find.

JavaScript

The biggest change in the last 5 years has got to be JavaScript. Wowee! Something happened and JavaScript exploded. We’ve gone from having a sprinkle of jQuery to enhance our sites, to JavaScript being embedded in every part of our build.

JavaScript compiles/transpiles our code, it runs our server, it runs our client, and it even powers our package manager. JavaScript is embedded in the core of the modern web, rivalling HTML and CSS.

We write all our JavaScript in ES6 syntax and transpile back to ES5 with Babel. jQuery has gone and our DOM manipulation library of choice is React.

Images

Fun fact: one of our top Google search referral terms on the old site was “Gavyn McKenzie Resize”. Not really sure why people liked our image resizer so much, but there you go.

With the release of the iPhone 4, retina was a big thing in 2012.

We used a combination of JavaScript and PHP to lazyload a request for the image to the server, which would fire back a cached image at the correct pixel size for the current display.

Our new image technique is a lot simpler, takes more effort, but produces better results. We make Jim Ramsden do it by hand.

A well optimised image, crafted manually and served up at double pixel density, can actually end up smaller than an automated responsive image. When it’s your own site you want every last bit of polish and the extra effort can be worth it.

Icons

Icon fonts are still a thing. Whilst we might be more likely to jump into using raw svgs instead now, icon fonts are super convenient and easy to use.

We’re still using Icomoon to generate custom icon fonts for us so we don’t need to include entire libraries.

We have a React icon component now that can check the icon exists in our icon font and throw a warning to Raven or Bugsnag if any unexpected icons are requested.

Font loading

The one thing that really hasn’t changed much is font loading. We’re still using the awesome web font loader from Typekit with a few cheeky fallbacks for slow connections or those missing JavaScript.

Automation

Everything was a lot more manual on the first site. These days, we have kicked the automation into high gear so that we can get on with making software instead of checking up on it.

We use Husky to add a range of git hooks that keep our code tight. All the Sass and JavaScript is linted pre-commit. Any linting issues that can be tidied automatically are cleaned up with prettier. On pre-push, we run a suite of jest tests to check everything is working as expected. When you pull from origin, we auto run yarn to make sure the dependencies are all up to date.

In contrast, the 2012 site was just commit and go with none of these quality checks!

Deployments

Our deployments used to be pretty manual as well. To deploy, you would have to SSH into the live server (the horror!), pull from the live branch and run the build script to clear out the template cache. Grim.

In 2018, we push to the production branch on Github. The build is picked up by TravisCI, which runs our linting and tests again, before compiling a production build. Whilst this happens, Codacy checks all our commits for code quality and complexity.

After passing the tests, Heroku automatically deploys the site. Our service worker picks up that new files have hit the server and let’s our users know they can update to the latest version by refreshing the page. By removing the manual load and setting up tests to help us stay confident, we can deploy any time, any where.

Internet speeds

So the site is in the browser at last! How have internet speeds changed in the last 5 years?

The average UK broadband speed in 2012 was 9Mbps. Fast forward to now and it’s over 50Mbps!

On mobile, we’ve seen a massive increase as well, from 1.5Mbps to over 26Mbps.

Number of requests

With all this extra internet available, how have we been using it in the browser?

Well, we’ve gone from 50 requests on our home page to 15.

OK, we used to have a lot of images. If we ignore the images then the sites are actually pretty similar, weighing in at 15 and 13 requests each.

Download size

What about the overall download size? Our old site was a whopping 13.7Mb on initial download (awkward!), although 13.5Mb of that was lazyloaded images so it didn’t prevent you getting to the content.

Our new site weighs in at 270Kb. Not bad for an SPA!

Again, if you ignore all the images, both sites are pretty similar. The difference is we’ve managed to squeeze a lot more power into the same space.

Browser support

Cross browser support is still a big thing, but not the all encompassing nightmare that it used to be. In 2012, we were still dealing with some pretty crazy old versions of Internet Explorer and our old site supported all the way down to IE7.

These days, we have a policy of officially supporting all browsers with over 1% market share in the UK (or worldwide depending on the client), according to the data on CanIUse.

This leaves us supporting Internet Explorer 11 as our “worst” browser, which is not a terrible place to be! Our main issues these days are quirks with Flexbox, CSS Grid and SVGs, which show up in IE and Safari.

Animations

Animations are always the fun bit you get to add on at the end if you have time. I like to think of them as a little treat if I’ve been good and got the site done with time to spare. With your own site, the whole thing is a delicious treat so we tend to get a bit carried away animating things.

The old site had a custom JavaScript grid that I wrote after understanding how to do it in a dream. I came into the office one morning and wouldn’t talk to anyone until I had it finished.

We would animate the top/left/bottom/right positions of our grid units so they would “smoothly” flow to the correct position. Unfortunately these properties are known for creating jank, so we try to stay away from them these days.

In 2018, we spend a lot more time in the performance tab in Chrome DevTools tweaking and tweaking to try and squeeze every last bit of frame-rate out of our animations. 60fps is the goal, for as long as possible during an animation sequence.

The Team

Finally, 5 years on, we’re a little bit older, a little bit wiser, a little bit beardier, but we still have the same goal: Make Better Software.

TL;DR

It takes a lot more code and a hell of a lot more npm packages to build a decent website in 2018.

However, we like to think the end result is a whole lot better.

Etch.