Reimagining our front-end architecture at Yuppiechef.com
--
A prequel article
“Make block. Left, right. Up, down. Side, side. Breathe in, breathe out. And no scare fish.” — Mr Miyagi, Karate Kid
I know what you’re thinking, “Another designer jumping on the style guide, this-is-how-we-built-our-site-it’s-so-awesome bandwagon.” And, yes, you’re probably right. Mostly.
Unlike Ian Feather at Lonely Planet and Jacob Thornton at Medium — both of whom I wish to be like when I grow up — I don’t have a success story and our CSS is not awesome. Far from it. And what follows is both an attempt to bid homage to them and their predecessors’ genius, and explain the journey we’ve been on and where we’re headed at Yuppiechef.com.
A CQRS/ES server — using Clojure, Datomic, DynamoDB and Kafka — and Enlive HTML templating with BEM-convention Sass-compiled CSS awaits.
I’m not going to go too deep into the server-side stuff and the CQRS setup, other than to say that our lead developer, Deon Moolman, walks the fine line between insanity and genius, and that this new setup offers some big advantages to our front-end team. If you’re a hardcore dev, here’s your exit to his opinionated CQRS/ES implementation.
First, some history
I joined the Yuppiechef team in January 2013, just a few months after they’d outsourced the redesign of their, then, table-based e-commerce store.
Until recently, Yuppiechef has developed almost exclusively in PHP — using Smarty templating — on MySQL databases. Admittedly, I’d been hacking together custom WordPress sites for paying clients before I joined, but my passion has always been for design, the beauty and semantics of HTML, and cracking the architecture of CSS.
The redesign, as far as I can tell, was partially built using bits of Twitter’s Bootstrap framework and compiled using an early version of the Less pre-processor. The design was great and of its time (we’ve since redesigned iteratively), but what resulted in our code was a hefty sandbag of over 300kb, deeply-nested, overly-specific, not-very-well-written CSS. It was no one particular person’s fault, none of us really knew any better.
At this point in our story, I could almost copy and paste, word-for-word, Jacob Thornton’s paragraph about cruft and nesting, zero re-usable components and all the unfortunate patterns that emerged from diving deeper into our stylesheets. Medium’s story of historical mess and ours are very similar. They’ve overcome a lot of it and the result is remarkable. We’re getting there, slowly but surely.
We also had (well, have) an M-dot website — mostly because bandwidth in many of the countries we ship to is an issue, but also because we believe the mobile shopping experience is quite different (Mat Yurow agrees). Yes, this does also mean two lots of code to maintain.
In August of 2013, Yuppiechef also acquired the League of Beers — an online store that sells local and international craft beer — and migrated their site from WordPress to our our codebase. Yup, more code to maintain.
There was a lot to do.
But will it scale?
At Yuppiechef, we build. A lot. Ourselves. All. The. Time.
What this has meant for our CSS though, is that — by our own doing—we’ve built more and more on top of this behemoth, too afraid to delete or refactor what’s there lest we ‘break’ something.
In June 2013, I came across Brad Frost’s post on Atomic Design and, soon after (or maybe even before), several articles on Yandex’s BEM syntax. This opening quote from Brad’s article resonated with me:
We’re not designing pages, we’re designing systems of components. — Stephen Hay
I’d had an idea floating around for a while. It came out of a discussion with a freelance journalist friend, Gill Moodie, about the naming conventions of traditional newspaper layouts. Coming from a traditional print background myself, the idea of columns, mastheads, earpieces, abstracts, titles, callouts and the like, got me interested in developing a naming convention for my CSS using the same. After all, it’s called a web ‘page.’
The idea developed a little further after reading Frost’s post. If the intention is to design components rather than pages, could we use the principles of newspaper layout and the BEM naming convention to a create a predictable and scaleable UI pattern?
Abstraction, components, and the separation of concerns — how difficult can it be?
Our plan is simple. “We need to bootstrap ourselves.”
With some interrogation, we could, can, hopefully, slowly but surely distill the vast number of interfaces and interactions on our site down to a smaller number of core components — patterns, if you like. Each one of these could have its own corresponding bit of (responsive) CSS. And, what’s more, we could use these shared components in both desktop and mobile applications until we move to being fully responsive.
All of this still assumes PHP. And then we had another idea.
Could we separate our code concerns even further, by removing any logic (read PHP) from the view templates? Could the pure front-end guys be left to write raw, readable, maintainable HTML (and CSS) and then populate these templates with data ‘directly’ from the database using CSS selectors?
Turns out, we can.
We’re already using Clojure for our self-made warehousing system and a few APIs to pull content from our WordPress blog to the storefront. We could, over time, migrate all our code from PHP to Clojure and use Enlive to create our HTML snippets and components. It all looks very promising.
Enlive’s greatest strength is that it decouples design and presentation logic. Each Enlive snippet is plain HTML. There are no special tags or attributes — no ‘code’ — though our plan is to use ‘functional’ CSS selectors prefixed with “fn-” to scrape and attach content to the templates.
HTML sorted. But what of that 300kb sandbag of CSS?
By using a CSS preprocessor and compiler, we could split as many of the readily identifiable components, pages and sections of our site into separate files — the hope being that it’d be easier to navigate through these and change or drop bits and pieces as we needed. And by using variables, mixins and some clever functions, we could standardise our on-site brand colours and typography.
We’ve settled on Sass.
Some quick facts about our existing CSS
- We design and develop (almost) everything in-house.
- We’re carrying a hefty (300kb) sandbag of legacy CSS — this is the ‘almost’ bit which was largely outsourced back in early 2012.
- Yes, we still have an M-dot mobile site, for now.
- We have, over the last while, been cleaning this up and migrating to Sass — comprised of over 170 individual source files.
- We don’t use frameworks (though we do like some principles of InuitCSS and Semantic UI).
- Nowadays, we write our CSS using strict BEM conventions — and learning as we go.
- We’re migrating our customised Font Awesome icon font to SVG icons, using Ian Feather’s methodology and Grump Icon.
- We’ve started using Respond.js to manage media queries for IE8.
- We’ve started using Autoprefixor to vendor prefix our CSS3 rules.
- We use Nginx and a bunch of other fancy stuff to do our builds and compilations.
Lessons we’ve learnt and the road ahead
A summary of what we’re aiming for:
- A unified design, taking all our products (including the storefront, magazine, online cooking school, wedding registry and forum) and standardising components based on design and functional commonalities
- A clear, predictable and scaleable CSS architecture to match
- A UI toolkit (pattern library)
- A retooled workflow, comprising Enlive HTML snippets, Sass-compiled CSS and Grunt tasks
In a line, the road ahead looks bright. And while there’s a ton of stuff to do in order to get us to where we ultimately want to be, I believe we’re in a stronger position today than we were 18 months ago.
The greatest lesson we’ve learnt is that to bring this vision to life takes a team and takes time. We’ve got a great team, and we’re having conversations and getting the plumbing in place for some truly exciting stuff. I can’t wait to write about how we did it.
“The future was uncertain, absolutely, and there were many hurdles, twists, and turns to come, but as long as I kept moving forward, one foot in front of the other, the voices of fear and shame, the messages from those who wanted me to believe that I wasn’t good enough, would be stilled.” — Chris Gardner, The Pursuit of Happyness
A hat tip to Andrew Smith, Noel, Chris, Cherryflava and Mandy who encouraged me to write this. Thank you.
