Modern tooling

There’s a sentiment among web developers that seems to me to be more prevalent lately, a bit of a reaction against modern tools like CSS preprocessors, task runners and package managers. It’s pretty well summed up by two tweets:

SASS LESS node Bower Grunt Gulp Brocolli Yeoman Git markdown polymer Coffeescript. No wonder no-one has time to care about accessible HTML.
— Bruce Lawson
Starting a basic website in 2014:

  1. Install Node

  2. Install Bower

  3. Pick CSS framework

  4. Pick responsive approach …

  5. Write some HTML

— I Am Devloper

I disagree with this sentiment and to summarise why I need to explain how I built websites before I used these tools.

I would have a bit of a boilerplate — a basic HTML5 setup with <!DOCTYPE html>, a head element with all the useful meta elements for character set, responsive design, description and a couple of other things, a title a link to a stylesheet and the HTML5 shiv.

Below that was the body with not much more than a script before the closing </body> tag.

Then I would just get started. I would write the markup first, as semantically as I knew how then move on to the CSS file and finally any JavaScript the design called for.

I didn’t use version control either. If I wanted to try something I either had to have the foresight to make a file backup (which invariably got messy if I needed it) or be prepared for a lot of Ctrl+Z presses to undo everything across several files. And you’d better hope you don’t close any files when that’s your workflow!

I knew then, as I know now, that accessibility is important. I knew that performance, progressive enhancement, semantics, maintainable CSS, compressed and minified JavaScript, device agnosticism are all important and part of a well rounded website. The problem was I didn’t have the time to do them all.

My boss at the time would take me to one side and tell me I had to spend less time trying to get them all right.

I would write JavaScript then manually run it through a minifier before copy/pasting into a new file. Any time the JavaScript needed updated I would have to go to the HTML source, change script.min.js to script.js, do what needed done then go off to the minifier again.

You can imagine what debugging was like.

CSS was pretty much the same. Two separate and completely independent files sat side by side in the /css folder, one manually minified the other was what I initially wrote. The problem was even worse with the CSS though. Because minified CSS is to some degree readable I often got lazy and just updated it rather than do the write, copy, paste, minify, copy, paste dance.

I can remember plenty of times when I just slapped some new CSS on the end and deleted the spaces and line breaks by hand.

Ridiculous.

So I was always left with a choice: pick one from accessible, mildly performant, cross-browser, well structured and semantic that I wanted to do properly and hope for the best with the rest.

Nowadays my workflow and output is so much better and it’s thanks to the tools that are getting a bit of a bad rep for getting in the way of good old fashioned web development. The opposite is true. They are doing the donkey work so I don’t have to.

I can now spend time figuring out exactly what ARIA roles and attributes I should be using on different types of modals/tabs/accordion/whatever.

I can now spend time testing my web page layouts, interactions and functionality on a wider range of browsers and devices.

I can now spend time figuring out how to enhance the web pages I build with more advanced CSS that only works on a few browsers.

I can now spend time adding structured data to my content where HTML semantics are broader than what is needed.

I can now spend time doing a PHP version of a fancy AJAX form so that access to my work is wider.

Practically it’s not that hard. I install node once per computer, not per website. Then I install Grunt, again just once per computer.

I have a modest starting point based on the old HTML5 boilerplate that allows me to write HTML, CSS and JavaScript in a /src folder and it automatically compiles to a /dist folder which contains the actual website.

Where previously I would have used PHP includes and localhost for even the most basic multi template sites I can now use a Grunt task to insert HMTL snippets in every page.

Installing a Grunt task is easy using NPM. For example just type npm install grunt-contrib-cssmin to install a CSS minifier that compiles /src/css/expanded.css to /dist/css/compressed.css.

I use Sass too. I love it because regular CSS is valid Sass. I’m not one for functions, extends and mixins in Sass (apart from one for media queries), but I do like a little bit of nesting and importing partial files. I also like being able to compile a CSS file for each template design in a site and not have to keep track of it all in my head.

With JavaScript I now create several files that have distinct functions and tell Grunt what ways to join them together and what to call the resulting concatenated and minified files it makes for me.

Performance is a huge beneficiary of modern tooling for me too. Now I run Grunt Critical CSS against each template and it’s corresponding CSS file to get a chunk of CSS needed to style the initial view. The HTML builder task then takes that chunk and inserts it into a style element in the head. To do that manually would take far too long to be worthwhile. (I know, I’ve tried.)

This is all just my personal experience and I think it’s important to have a decent instinct for what sort of tools will help you. Running around chasing every new one is probably not a good use of your time if your job is to build websites. There are plenty of people who will try them all and blog about it, so read their posts and decide for yourself.

Like any tool in any industry they are a means, they’re not the point, but nobody, no matter how good they are is going to be able to produce the same quality and efficiency as someone with good tools.

All else being equal in terms of ability and knowledge I think a developer using modern tools will make better websites than one who doesn’t.

*[ARIA]: Accessible Rich Internet Applications *[NPM]: Node Package Manager

Tags