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.
Back 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.
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.
The 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
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.