Learning New Tools

Up until very recently, I’ve been building websites using manual methods, or at the very least, using tools that locked me into a single developer’s update schedule. This worked well at first, but I’ve been gradually learning to expand my horizons, and Yeoman is just the beginning.

Last month, I was thinking about all the Craft sites I wanted to build, and was becoming exhausted always building the same basic system, over and over. I got the wild idea to ask Andrew Welch on the Craft Slack channel how he would recommend pulling files from a static location, perhaps using an Alfred workflow?

Andrew simply replied with a link to a repository of his, at the time self-named for his company, generator-nystudio107, but would later be renamed generator-craftinstall. I saw that it was a Yeoman generator, which I knew was supposed to help me save time building out a project, but I had no idea what it involved, or how easy it could make it.

After following Andrew’s thorough instructions, I saw the potential this setup had. Using the Craft Install generator, I also got a chance to dive into Gulp and npm. These tools have helped me create a great environment that runs lightning fast.

What about CodeKit?

As I mentioned, I’m not unfamiliar with preprocessors; they’ve been a staple of my setups since I started using CodeKit four years ago. But lately, I’ve been running up against slow processing times, as well as the desire to bring Bower components into a build without having the source live inside the web root. Having multiple projects added to the application can cause some undesirable slowdown; the proposed solution is to add and remove projects as one needs them, but this seemed like an unnecessary step where a toggle would suffice.

Enter gulp

As a side-effect of learning how to use npm and yo commands, I started to pick up gulp. Gulp is a fantastic automation tool as well that helps me run tasks while building my site. Where Yeoman lays the foundation, gulp helps me by handling processes I normally reserved for CodeKit, only much, much faster. There’s a million and one articles on how everyone uses their gulp setup to make automation a breeze, so I’ll quickly go over what sets this (and Grunt) apart from CodeKit for me.

Plugins

gulp-sass

Using gulp to process my Sass files has seen a huge increase in speed. Even when CodeKit is also set to use the libsass compiler, gulp seems to scream past CodeKit since it doesn’t have anything weighing it down; you aren’t trying to watch or process anything but the code in front of you.

gulp-postcss

PostCSS by itself doesn’t do much. Its power lies in how it uses various other JavaScript plugins to process and massage CSS files, listing, organizing and compressing along the way. Even if you aren’t using gulp-sass as a preprocessor, this is an absolutely essential plugin for two reasons:

  1. mq-packer
    While it normally isn’t a cause for concern, multiple identical media queries can be difficult for you or your team members to parse when staring at your styles. This PostCSS plugin will gather all identical media queries and place them together, cleaning up the total number of queries and making it far more logical to understand.

  2. perfectionist
    I love beautiful code, as one might guess from the previous plugin listed. But gathering the media queries isn’t the only way for code to look nice. Perfectionist helps organize your output CSS in a way that is instantly readable to any user, and even adjusts visual cascading of vendor prefixes, which is a useful tool when you are using autoprefixer.

gulp-livereload

If it weren’t for this plugin, I don’t think I could have found the strength to drop CodeKit. livereload reloads my browser html/js/css when it detects specific files being updated. The speed this occurs and its overall transparency are amazing.

gulp-load-plugins

This one is more for organization before I kick off automation than anything else. Since there’s a large number of plugins for gulp, specifically, it could get tedious writing out:

var gulp            = require('gulp');
var cache           = require('gulp-cache');
var sass            = require('gulp-sass');
var postcss         = require('gulp-postcss');
var livereload      = require('gulp-livereload');
var watch           = require('gulp-watch');
var concat          = require('gulp-concat');
var debug           = require('gulp-debug');

So instead we do the following and call only the gulp plugin and then run gulp-load-plugins to bundle everything up under a plugins. variable:

var gulp            = require('gulp');

var plugins = require("gulp-load-plugins")({
    pattern: ['gulp-*', 'gulp.*'],
    replaceString: /\bgulp[\-.]/
});

Speed

This thing is fast. Like, really fast. On average, most of my changes take ~ 150ms to recompile and reload. Compared to CodeKit often not even responding until the app was reloaded, it really is no contest for me. I feel like I can accomplish more when the results are instantaneous.

One Less App (to look at)

I can’t stand having extra icons in my dock or my menubar. Having all of this run and live inside of a terminal window means I can SSH, I can run commands, etc., all under the single, tabbed window. The reduction in clutter is well worth it.

In Summary

I know that this is just the tip of the iceberg, and there’s plenty I didn’t even touch on, but if there’s one takeaway I would want anyone to have from this article, it’s this: go ahead and try that workflow or plugin or app you’ve been wanting to. You definitely will end up spending extra time learning how to incorporate it into your workflow. But once you have it running, and things are predictable and smooth, you’ll be surprised at how easy it is to focus on the parts of the project that really matter.