Customer PortalThe 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.
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.
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.
