The Flat Build (2)
My article The Flat Build was a slow burner but it has picked up steam recently and for the first time in like, forever, I’m building a pre-designed* website without having design influence. This has proven to be a good opportunity to refine and expand upon my flat build workflow (again).
I’m aware I’m reinventing more than a few wheels here. This project has always been about starting from the ground up and questioning every choice.
* Yeah, I’m a big advocate for agile “decide in the browser” web design/dev, but I have to admit that a beautifully maintained PSD deliverable still feels like Christmas.
I’ve always maintained a personal set of HTML & CSS files to use as a starting point for any build. Mostly good practices, general preferences, and stuff I forget like the favicon.
This practice has never actually helped me remember the favicon — you have to love boilerplate deployment — but after catching up with Chris Coyier’s screencast I have a new found love. I’m currently writing the favicon-first manifesto…
I use Git as source control for everything. This includes my boilerplate which I can evolve and fork for new projects. Starting a new build requires these steps:
- Initialise a new Git repo
- Merge in my boilerplate code
npm installto pull in dependencies (basically Grunt + tasks)
And yes, I work on the master branch and name my devices after monkeys.
As you can see my project directory structure looks like this:
build directory is generated by Grunt and never committed to Git. It contains the final static website with no outside dependencies. I can view it in the browser, archive and email to a client, toss on a server, or just delete and rebuild it entirely for a laugh (that novelty wears off).
templates directory contains HTML (I should probably move this into
src for consistency). My HTML Grunt task — new and improved* — lets me separate HTML includes and reference relative assets or paths. All without server-side scripting.
* use at your own risk.
The complete set of build tasks can be quite slow so I need to build individual components as and when they are modified.
Who watches the watchmen?
I’ve been using Compass for a long time to generate CSS. With pre-processors you get a nice command line programme to watch for changes and automatically generate plain CSS output. This alleviates the burden that an extra step adds.
With my new practice of separation between source and build I need a more powerful watcher. Grunt watch comes to the rescue. For each requirement I instruct it to watch a set of files and then perform a specific task. HTML is edited? Rebuild it. CSS changes? Recompile it. SVGs are modified? Optimise and create raster fallbacks (OK, I haven’t perfected that yet).
Whenever I’m working on a project I just run
grunt watch and let it go.
Like I said, none of this is particular ground breaking but I’m learning a huge amount by starting from scratch. I could jump straight into an existing solution like Yeoman but I’d never really understand the “why” behind the process. My quest is automation and I’m already making life easier. Even with the less than optimal set of tasks I’ve hacked together.