This is Part I of a three part series about wd_s, our starter theme.
- Part I: History of wd_s
- Part II: Project Scaffolding with wd_s
- Part III: Future of wd_s
One of the most exciting things of my job here at WDS is getting to spearhead our internal starter theme: wd_s. It has come a long way since its inception (a fork of Automattic’s Underscores) and it’s a thrill to help mold it into something that our agency uses on every project. Though it hasn’t always been that way…
In the spring of 2013, WDS started to take on more enterprise level clients. Internally, WDS was also hiring more and more developers to match the workload. Our internal project workflow was also pretty fluid. Developers were assigned to projects based on individual availability. The first person to start a project would generally spin up a Genesis child-theme, or use our own premium theme Startbox, or maybe even choose a theme they were familiar with.
Shortly after I was hired, we kicked off a build for Securelist. Based on my availability, it was up to me to choose a theme. Naturally, I asked around to see how everyone felt. Because of some recent hires, not everyone was familiar with Genesis or Startbox. Given the size and scope of this project, we decided against Genesis and instead I opted for TwentyThirteen.
Deconstruction Can Sometimes Inhibit Construction
Let me set the record straight: Genesis is fantastic. It’s stable, secure, and mature. I’ve contributed to the codebase, have been known to champion it in a blog post or two, and even have a Sass version on Github. However, for large, 100% custom builds, working with an opinionated hook system instead of actual template files can get pretty awkward. As rock solid as Genesis is, it doesn’t exactly follow what WordPress considers “the standard” way to build a theme either. By choosing TwentyThirteen, we were able to get a bunch of real template files that adhere to WordPress theming standards. This was important, since there would be a few us working on this together, and we needed to maintain the code for an extended period of time; and potentially with a bunch of new hires.
If you’ve ever worked on a single build with a group, you know how important standards are. It’s really hard to work (together) if there isn’t a baseline set of rules. That is exactly what frameworks like Genesis, Bootstrap, Foundation, jQuery, etc… provide: opinions and standards which are there to help you get things “done” faster. When a development team is familiar with these standards, you maximize profits. However, too many opinions and rules can also inhibit construction and, frankly, get in the way.
Growing Pains
By the fall of 2013, Underscores was really gaining traction in the WordPress community. It’s an unopinated “bare bones” theme, built specifically to help you and I get a theme up and running quickly. What’s more is, it’s built upon WordPress theming and code standards. It’s also maintained by engineers from Automattic. For all intents and purposes, it’s the “official development theme” of WordPress.
We took notice here, and wondered what it would look like to combine the best things of Underscores with our own premium theme framework, Startbox. Brian Richards and I spent a few weeks that winter trying to create a product that would be both unopinionated and provide developers with an excellent starting point for projects. Brian integrated an amazing collection of template tags, the Theme Alliance hooks, and I converted all the CSS to Sass and added support for Grunt. Just reading the changelog is making me all kinds of nostalgic!
During StartBox’s development, WDS was still growing rapidly. 2014 would be here soon, and some huge projects were coming along with it. Even though we had made significant progress on StartBox, it was decided that StartBox would be shelved. Startbox wasn’t the only WDS premium product to be shelved, WDS simply did not have the bandwidth to maintain some of our premium products in the face of client work. The math just didn’t add up.
Gettin’ Sassy
Undeterred, we immediately decided to take another look at using Underscores. Having worked with it while trying to get the best parts into Startbox, plus all of my experience with Sass, I created a (very basic) Sass template which we would use with fresh clones of Underscores.
In February of 2014, we were frustrated with having to apply this Sass template over and over for new builds. I decided to submit a pull request which include a (very basic) Sass implementation. This pull request sparked a 5 month long discussion. After much debate, Sass was finally added in July of 2014.
While this was a huge win, it just took too long. While I believe it is paramount that WDS use what I call “the official development theme” of WordPress, we simply could not wait for development tools like Sass and Grunt. We decided to fork Underscores.
WDemocracy
One of the other things I love about working here is the democracy. We have a weekly call with just the Front-End Developers where we talk about all kinds of things front-end related. We also discuss the features, pain points and the roadmap for wd_s. Just scroll through the Github issues and you’ll see the democracy at its finest. Before we forked Underscores, we set a couple of rules:
- We would try to stay as current as possible with Underscores.
- No versioning, releases, milestones, or tags.
- No opinions outside the tools necessary to do our jobs.
Once we forked, we immediately got busy doing cool things with Grunt, like adding support for sprites, javascript concatenation, minification, and SVGs. We added support for Livereload, PostCSS, Bourbon and Neat too.
More Than A Starter Theme
Having all these front-end tools available has it made spinning up a new project efficient . It’s become a teaching tool too. Many of the people here who’ve contributed to it, had never contributed to an open source project before. It’s also become a testing ground for front-end theory. We’re able to play with the latest front-end trends like SVG sprites and PostCSS – and really put these workflows through their paces.
Not every new “trendy” thing ends up staying in the theme, we dropped Font Awesome in favor for SVG icons after clients complain about Font Awesome icons looking terrible at small sizes. Because there’s no versioning (or worry about legacy support), my favorite “feature” of wd_s, is how fast we can adapt and adopt to keep pace with how rapid front-end development moves.
Join Us
wd_s is about eighteen months old and is it perfect? Nope. But it’s also not opinionated either and has just enough rules to allow for agile development. wd_s provides an excellent starting point for developers to spin up a new project. We invite you to fork our starter theme. Kick the tires, poke it with a stick, make a pull request of your own, and join the democracy! We’d love to have you: https://github.com/WebDevStudios/wd_s
Comments