Yesterday I wrote about the nine steps in my starter theme workflow to get things set up and running (the post is about my WordPress starter, but process is very similar for Shopify). I name dropped a bunch of code tools (processors, languages, task runners, and so on) and today am going to attempt to give a quick explanation of what those things are and why I use them.
Before I dive in, I wanted to mention that I was kind of resistant to adding this stuff to my workflow – regular old CSS and manual task running was working fine and I didn’t feel like I had the time to figure out these new things.
However, a lovely combination of a push from one of my associate devs (thanks, Kim) and the realization that all these things could actually work together finally had me trying it out. I’ve seen a noticeable efficiency boost even though I’m barely scratching the surface of these tools, so I won’t be looking back.
Git is a free, open source version control system. I mainly use Git because it makes sharing files and collaborating easier, although I am certain if I ever need to roll back to earlier code I’ll appreciate the history as well.
A common point of confusion is whether Git and GitHub are the same thing. Git is the source control system, GitHub is an online storage and tracking system for projects using Git (kind of like a specialized Dropbox). It also includes features like issue/ bug tracking and wikis. I mainly use GitHub for open source projects (where I want to share the code publicly) or projects that will eventually be open source, since you have to pay for private repositories.
Bitbucket is very similar to GitHub – online storage and tracking for repositories – but they offer unlimited free private repositories. We use Bitbucket for client projects, but keep public projects on GitHub mainly for the community aspects (also the web interface is a little nicer on GitHub).
CSS & Browser Prefixes
Sass is what is apparently called a “CSS extension language,” which I interpret as “a different way to write CSS that requires conversion to normal CSS before it hits the browser.”
After a long period of resistance to trying Sass (or LESS, an alternative), the turning point came when I started looking into task runners and realized that everything could be done all in the same easy package (no need for another GUI).
I currently only really use the variables, nesting features and a fairly limited set of mixins (all those terms are described in the Sass Basics guide). Even with only those features in play, it has made my working files much easier to read and update.
In addition to the documentation on the Sass site (which is well done), there’s a nice beginner’s guide to Sass on Web Designer Depot that’s worth checking out.
Side Note on Compass: I don’t have strong feelings on Compass, which works with Sass and has a bunch of mixins built in. I can see the utility but I’m more the type to roll my own. Right now one version of my starter uses it and another does not.
I found out about Autoprefixer after reading about it on CSS-Tricks (as one does), and added it into my task runner workflow from the outset. It’s a tool that processes your CSS and adds all the necessary vendor prefixes based on the CanIUse.com database.
Evidently Compass does similar things but I like this method because I don’t have to even consider prefixes or mixins. It’s all done for me and it’s kept up to date automatically.
I was inspired to try Grunt after reading Chris Coyier’s 24 Ways post called “Grunt for People Who Think Things Like Grunt are Weird and Hard”.
Essentially, Grunt is a tool that runs a bunch of processes on a set of files. That can include everything from Sass processing to Autoprefixing (those are what I use it for) to image compression, code testing, and much much more.
Gulp is basically the same thing as Grunt, but with a different method of structuring the processes. I like it mainly because it’s faster and I am impatient, otherwise I don’t have a very strong perspective (some people do – there are lots of Grunt vs. Gulp articles out there).
Gulp is a little bit newer so there are not quite as many options for things it can do, but all the stuff I need is covered so that doesn’t impact me. I used this tutorial by Travis Maynard, which starts at the absolute beginning (installing Node.js), to get going. Here is my current gulpfile in case it’s helpful to see one.
Update: A Note on Watch Tasks
Shortly after I published this post, a question on Twitter reminded me that I forgot to mention one of the key benefits of these task runners, which is watch tasks. You can set up a special task that watches a set of files and runs some tasks whenever a change is made.
For example, I have my watch task set to keep an eye on all my
.scss files and every time I make a change in one of them it automatically processes the Sass and recompiles my minified CSS file, and then if I have LiveReload turned on the browser, it also reloads the styles so I can see them change in real time.
It’s basically magic.
Deployment via DeployHQ
While I’m leaving out the desktop applications mentioned in the original workflow post, I did want to mention DeployHQ, which is an online deployment tool that links up remote repositories (e.g. from GitHub and/or Bitbucket) to a live server on a hosting account.
I’ve written about deployment options in the past, if you’re interested.
Automatic Configuration via Yeoman
Finally, we’ve just started to play around with Yeoman, which will allow us to cut 4-5 steps out of that workflow I posted about by automating them via a configuration tool.
When that is finished, I’ll be able to run Yeoman from the main folder where the configuration tool and starter theme files live. There will be a series of questions (with sensible defaults set), and the new theme will be created based on the answers. It’ll handle the naming conventions, installing the task runner of my choice, and a few other things. It’s pretty amazing, really.
It took me a few (very interrupted, weekend) hours to get my first generator mostly working (it currently works if you opt for Gulp but fails if you choose the Grunt option), mainly using their getting started guide. The Treehouse blog also has a Yeoman tutorial.
Also, this is a great video of a presentation on automating your workflow that hits on both Grunt and Yeoman.
If you’re just starting to consider using these tools, keep in mind you don’t have to start with every feature or method that exists. My
.scss files are still large part regular old CSS, just reorganized into a clear nesting structure and with variables peppered throughout. I don’t use task runners for much other than CSS yet. That’s all fine – now I have the systems in place doing me some favors and it’ll be easy to add to them as I find other places in my workflow where it makes sense.