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.
Boilerplate
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…
Repository
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
- Run
npm installto pull in dependencies (basically Grunt + tasks)
Sublime Text 2 and iTerm (with oh-my-zsh) are my apps of choice for code management.
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/src/tasks/templates/Gruntfile.jspackage.jsonREADME.md
The 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).
The src directory contains the actual editable source and original assets; Sass, JavaScript, SVG, web fonts etc. The 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 basic principle here is to keep a single source for all working assets. If that isn’t the final output — e.g. Sass or un-minified JavaScript — the output should get compiled automatically. Similarly, I don’t want to manually maintain PNG fallbacks for vector graphics if they can be built from source. The whole set up is complex but the act of building is simplified.
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.
Next step
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.
I’ve written a lot about facilitating the build process but not the actual practice of writing HTML, CSS, and JavaScript itself. The most time consuming thing of all. I’ll follow up on that soon, for now read my 5 Tips for Responsive Builds and be sure to read Dave Rupert’s excellent article on Responsive Deliverables.
