How we do front-end

by Misha Rumbesht

Every project starts small and grows into something big later. And to grow it, there are quite a few tasks which can and should be automated.

Efficiency is essential for a small agency like Wild Dog, and in this bright age of the development tools over-saturation, one would seemingly just need to choose the right solution, and reap the benefits of automation-enhanced development. Unfortunately, it is not as simple as that. And even though there are great tool-sets out there, we needed something custom for our needs, which are:

  • Task runner
  • Templating language to generate static HTML from
  • ECMAScript loading, package management and transpiling to allow ES6+
  • CSS framework and critical css generation
  • Image optimisation
  • Icons
  • Automated deployment

That doesn’t sound like a lot to ask for, does it? Here’s what we came up with.

Gulp all the things

In the old days we used to rely on Grunt to run tasks for us. Alas, though very helpful, it was also slow. Especially, if there were many images involved. We tolerated that – it was only during bundling the project for production that it was slowing us down, after all. The break came when we tried to introduce Babelify to transpile javascript – most of the time it simply wasn’t coping with the load.

That is how the switch to Gulp happened. Its in-memory processing of streams is a much better way to run chained tasks. And it is much much quicker compared to Grunt. Win win.

Laying out the HTML

In the Grunt days we used to rely on Liquid for templating. As great as it is (folks at Shopify are doing a tremendous job with it), it really lacks support on Gulp. Not only that, but even the Grunt plugin was failing after Grunt’s big update to version 1 (if anybody is curious, we solved the problem here After some deliberation we went for Nunjucks. It’s a great project run by the bright folks at Mozilla. And seeing that it is very similar to Twig which we use in our WordPress implementations, it was really a no-brainer.

Future-proofing Javascript

We use JSPM for all things Javascript. It is a package manager for SystemJS module loader. It allows us to write ES6+ code and use JS modules natively. It’s liberating, really. JSPM offers its own registry of the popular repositories, but also allows installing modules from NPM and Git. In production, we create a self-executing bundle to be asynchronously loaded in. Using Airbnb linter helps in keeping the coding practises consistent.


CSS is seemingly plain and simple, but can be terribly hard to maintain. It isn’t much fun diving into the 20k+ lines-long CSS file at all (fun fact, IE9 only supports 4095 selectors per sheet – not that anybody should be bothered with IE9, really). To keep CSS maintainable, we’ve chosen to employ BEM element naming conventions. If curious, read this article by the great Harry Roberts. We use the (slightly modified) inuit.css framework, which allows us to be modular with the CSS we produce, reduce the complexity of the compiled CSS, encourage code reuse and separate the layout and code semantics. So many wins. Who cares if the class names look “ugly” (which I don’t really agree with, anyway) when it brings with it so much clarity?

We also hand-pick the classes needed for the critical css, and generate the separate critical css blob for production build. This allows us to load CSS asynchronously using Filament group’s loadCSS technique, making the pages display much quicker.

Sharpening the icons with SVGs

In the old days, icon fonts were the hot stuff. Not anymore – it’s all about the power of SVG iconsets nowadays. The technique has been around for a while (see this great article from 2014), but only recently became universally recognised. And rightly so – it really does make your icons shine. We use gulp-svgstore to automate the SVG symbols store generation, and load it in as a separate file. There are some compatibility issues, which are tackled by using svg4everybody.

Automating the deployments

The last task is delivering the built-up project to the server so that the client can check it out. It would be very tedious uploading it manually every time – thankfully, there are tools to automate this task. Flightplan is one of them, and a very good one at that. We have a ‘deployer’ user set-up on the server, which has all of our developers’ rsa keys added to the authorised_keys file. It makes the task of controlling who can deploy the projects to the server very easy.

Wrapping up

All of the techniques described above were gathered together in our own Puppy project. Give it a try, and we really hope it will make your day-to-day front-end development tasks easier, leaving time for well-deserved fun.

Image: With many thanks to Bones-Mello-the-AT-AT-Dog for such a great image