Assortment of white-out logos of development tools: GitLab, Sass, Gulp.js, Node.js, and Grunt.js

Tools of Our Trade – 2016

The web is full of shiny new toys to play with. This can make it a bit overwhelming at times. A survey by Ashley Nolan—a Senior UI Engineer working at JUST EAT—regarding what tools web developers are currently using got me thinking about what we use at Twin State for front-end development. As a designer creating websites for a variety of clients, I have to stop occasionally and ask myself:

  • Is there a better way to do this?
  • Is there a faster way to do this?
  • Is my code going to be understood by anyone else who has to maintain this website?
  • If I use a new tool, are my coworkers going to be able to maintain it?

I work closely with our lead front-end developer, Geoff Lampe, as well as our programming team. Most of our recent clients have asked for custom-designed sites (as opposed to templates), which means that we get to develop custom-designed themes for our current CMS-of-choice: WordPress. Shared responsibilities means shared knowledge; I can often ask Geoff how to grab some part of a post using PHP, and he usually has the answer. Similarly, when Geoff wants to do something specific in CSS, I usually have suggestions.

Some habits of writing code can be overlooked, because they don’t prevent someone else from maintaining them. Geoff and I have our own CSS “dialect” when it comes to writing code—such as how we write our comments—but for the most part, our pre-2013 code was easily compatible across machines: jump on the server, edit a CSS file, and save.

Sass swoopy text logoBack in 2013, we made our first foray into using LESS a CSS preprocessor. We used this for our new web design sister site, and chose it over SASS due to it being backwards-compatible with regular CSS and its inclusion with our chosen framework at the time, Bootstrap. Preprocessing means compiling, so we eventually purchased licenses for CodeKit, and I abandoned my brief affair with Yeoman (which did way more than I needed). This prevented us from needing to learn the ins-and-outs of Grunt.js or using the command line, which can slow down your development if you aren’t familiar with it. This can result in going over your client’s budgeted hours, and it’s a hard sell to bill them for learning new techniques—and an uncomfortable conversation with the boss when your time could have otherwise have been spent on billable work.

That said, Geoff and I have come to accept that many of these technologies aren’t going away. Some of our programmers have jumped on board with various JavaScript frameworks for web applications, forcing us to learn them in order to continue collaborating and lending our visual skills. Developer Michael Harry has been using Angular.js and Gulp.js in a recent document repository project, two technologies that I have come to appreciate (at least once someone else has helped me get started). A former programmer of ours (who now works for Microsoft!) was instrumental in getting a GitLab installation in place so that our entire team could jump on board the Git wagon (where we had previously been using Mercurial). I’ve personally found a stable relationship with SASS (Syntactically Awesome Style Sheets, for the uninitiated). I’ve been using Sass for the past three projects I’ve been developing, and while I’m still finding my way around, I’m getting a lot of use out of reusable pieces such as variables and mix-ins. Perhaps even better, it gives me the freedom to separate my CSS into separate files and import them later. Of course, you could do this with plain old CSS, but CodeKit compiles it all into one file (and can even minify it for you), providing a single, speedy http request and allowing our sites to respond more quickly (with live reload built in, to boot). It also works great with a device lab.

Side note: We hosted a talk about the “state of the web 2015” last year, and a major focus was on site load times—especially critical on 3G and 4G connections on peoples’ phones.

NPM text logoThe other side of the coin is that, should Geoff need to dive into my code, he’s going to have to find his way around—we don’t write code the exact same way. Similarly, if I’m using some extra tools, such as Susy for grid layout, he’ll need to install this via the Node Project Management or Ruby command line.

Some tools make this relatively straightforward. When working with NPM, a file is automatically generated to keep track of the dependencies you’re using. A simple

NPM install

will pull down all the necessary bits you need to work with. That still leaves the hurdle of actually knowing how to operate the system—what other environment commands to run.

New stuff comes with new problems, but that’s the beauty of web development: there are always new things to learn. And if you’re a fan of efficiency, there’s probably a way to achieve more of it in your code. However, when you’re working in an agency, you have to learn to curb your enthusiasm: you’re not the only one here.

Susy text logoNext on my list is to start using BEM for more easily readable CSS, and Suzy for easy grid development. PureCss.io has been good to me, but I think it’s time to break from a static grid.