It’s been a while since I published Part I of the Bones and Underscores a tête-à-tête. Honestly, I didn’t think writing a follow-up would take half as long as this, and lots of people have been asking what my conclusions are. I’m happy to report that after more than a year, I have reached a conclusion!

[ drumroll ]

I’m delighted to announce that the winner of the Bones vs Underscores death match is: neither / both! (Come on now, you knew there wouldn’t be an actual winner!).

So, on to the details. The reason this post has taken so long to write was that I’m only now realizing what I want to say about both themes. I’ve used _s the most since it came out — I’ve probably built 10+ themes with it as the foundation — and so it was really hard to judge Bones against that after just some light playing around. In the last few months, I’ve gotten to build a few new projects with Bones (this site is one), and I’m in a much better position to give some honest feedback about what I think of them both. Let’s get to it!

Bones

Mobile first

When I first started playing with Bones, I didn’t know what to make of the whole mobile first thing. It was my introduction to this design approach, and was much different than the typical pattern of throwing rules at media queries in the bottom of style.css and calling a site responsive. Mobile first really forces you to think about the most basic elements of your site and build up from there.

With Bones, you start with the _base.less file (if you use LESS), and build up. An easy way to think about it is to think of _base.less the same way that you would think of your typical smallest media query. So, anything you would put in that media query to affect the look of your site on phones should go in that file. When you’ve got that roughly the way you want it, you move on to the next size up: the _768up.less file. This will affect screens from 768px wide and up. Anything you want to have happen on an iPad or a desktop or a laptop, you put in here. If you’re used to tackling media queries at the end of a project, it will probably feel a bit painful to have to think about phones and laptops separately, but once you’ve spent a few hours in this mindset, it quickly becomes natural.

Even if you have no intention of ever using Bones, I’d still recommend building a site using it, just to get the benefit of being exposed to the mobile first idea. Mobile first seemed so unnecessary and almost pretentious to me last year, but now it feels 100% the right way to do things.

The big piece of getting this was realizing that mobile first refers to the process not the product. I used to think: “Meh. Only 20% of my visitors are on mobile, so why should I start with them first?”. But it’s really about thinking of the mobile part as a foundation — start with small screens and lay out all the foundational elements — colours, type, visual elements, etc — and then layer on top of that. Only add what you need as the screen size changes. It doesn’t mean designing a fully-functioning iPhone site before even thinking about your desktop site — it means only adding or layering on the bare minimum to each successive size up. If you’ve laid a solid foundation in your _base.less file, you’ll likely have add very minimally to the other screen sizes. In short: mobile-first doesn’t mean extra work.

End tangent. That was a lot more about mobile first than Bones specifically, but it was huge, huge, huge for me. Hopefully it will be a good introduction to mobile first for you as well.

Stylesheet partials

Being a fan of _s for so long (and it’s predecessor, Toolbox, for longer) I’d grown accustomed to having just one stylesheet to manage— style.less — the one-stop-shop. I loved the simplicity, I loved having everything in one place. It was great. Until I saw a better way. Bones has everything broken out into partials — there’s a partial for the base styles, another for each media query breakpoint (480, 768, 1030, 1240) as well as others for retina screens, one for normalize.css, one for print styles, one for mixins, one for the grid, etc. IE: lots of partials.

I really found this unnecessary and inefficient at first. I had to search around to see where everything was, and I was never sure if I was putting things in the right place. To be honest, it was pretty frustrating. But slowly, over time, I began to see the natural breakdown of styles. I started to get the whole mobile first thing and I swapped in my own grid system and added some of my own mixins, and pretty soon I was actually thinking in partials. It just started to make sense to have things in different files, separated by the things that concern them.

 get_template_part()

As of this writing, Bones still doesn’t implement the get_template_part() design pattern that I love so much. I really hate overloaded template files, and so I simply had to change that if I was going to continue working with Bones. In the end, I took that approach from _s and morphed it into my fork of Bones. The result is much lighter template files, and a bit of reduced repetition. It might not bother you, but it was a real deal-breaker for me.

Underscores

The name

I hate the name. Having to do a complicated search and replace for the string _s has never once worked out properly for me, and so in all my old projects I’ve just left references to _s, rather than try and weed them all out. It’s probably a minor issue, but it’s been really frustrating every time I’ve gone to use it. I’m always left scratching my head, thinking “_s”? Is this the best they could come up with?

The barebones-ness

Underscores is very, very bare when you get it installed and activated. In fact, every time I activate it and go to the front page, my immediate reaction is to think that there’s something going on with my MAMP install. It’s completely bare. It does come supplied with some sample layouts, but really, if you’re starting from absolute scratch like this, you’re probably going to build your own layouts too.

Although any visual styling would probably need to be undone as you setup your new project, I still think it would make the starting point feel a bit more comfortable. Maybe it’s just the designer in me, but I always find starting a new project in Bones to be much more comfort/ing/able. I like to start with something, even if that something needs to eventually be removed. That’s just me.

But you may love it. It’s a completely clean slate, with almost no assumptions made about how it should look. That might be just what you’re happiest with.

The Buttons

The button styles are grotesque. There’s no way around those giant, hideous buttons.

Eric Meyer’s style reset

I mentioned in the original post that I really don’t like Eric Meyer’s stylesheet reset that Underscores uses. I still don’t. I prefer the normalize approach from Nicolas Gallagher, as used by Bones. Seeing my dev tools inspector window filled with line after line of needless resets just really frustrates me. There’s no need anymore.

The rest

That said, the rest of this theme is fantastic. Everything being done in this theme is being done for the right reasons and with good justifications. It’s been used and refined by all kinds of very smart developers who know WordPress inside out, so I really trust what’s going on in the template files. If you’re looking for the Right Way to develop a WordPress theme from scratch, I’d say to start there, without hesitation.

In short

You’ve probably guessed by now that I’m in the process of creating a Bones / Underscores Franken-hybrid theme. There’s just so much I love and hate with each one, that it seems natural to customize the best of both and make the perfect theme for me. I’ve started down that road here: Waterstreet on Github. You’re more than welcome to have a look and see how I’ve got things setup. A few things you might notice right away:

1. I’m pulling in content.php via get_template_part() wherever possible.
2. I’ve got Font Awesome hooked in and ready to go.
3. I’m using a grid inspired by the great work over at Mapbox
4. I’m using many of Underscore’s template tags

I’m still wondering if I should have forked Underscores added Bones, or forked Bones and added Underscores, but time will tell. At the moment, I’m fairly happy with the direction of our Franken-hybrid. Stay tuned!

Update: I’ve finally finished the follow-up post. Read the update when you’re all done here!

I have a big week coming up. I’m starting two brand new projects and I’m pitting two top WordPress starter themes against each other in a battle royale:

Underscores

First up, we have Underscores from the Theme Team at Automattic. It is very clean and stripped down, and truly satisfies the ‘starter theme’ criteria. It comes with the barest of necessities, but leaves nothing out at the same time. For you old-schoolers out there, you might notice that a lot of Underscores looks very similar to Toolbox, it’s predecessor. In short: Toolbox was a good starting point for developing themes and Underscores is a great one. Let’s have some pros and cons:

Pros:

• Underscores is familiar. This is really only important to me, but it still matters. I used Toolbox on a lot of projects, and still use my fork of it—Victoria Park—for lots of things today. I used Underscores a few times in the past few months and it really feels like an updated version of what I already like.
• Underscores uses the get_template_part pattern for abstracting template files. I really like this way of thinking about templates.
• Aesthetics matter and the website for the project is great.

Cons:

• Doesn’t use LESS or SASS. This is such an easy issue to fix (rename style.css > style.less and have LiveReload watch the folder) that it hardly warrants a bullet point, but it’s an important distinction from the direction Bones has chosen to take.
• The name. I’ve never really liked the name ‘_s‘, which is an extremely unimportant detail until you go to start a project and have to find and replace all instances of ‘_s’ with ‘my_project_name’. Again, it’s absolutely not a huge deal, but it was a bit of a pain. The pain is now pretty-well completely alleviated by the project’s website—you can now just enter the name of the project and all the finding and replacing will be cleverly done for you.
• Not responsive. I know, I know. You shouldn’t let a project’s boilerplate dictate your media query breakpoints, etc etc…and its something you can (should?) easily add yourself, but I still wish there were a few breakpoints baked in.
• Eric Meyer’s style reset. This one would have been so insignificant a few years ago, but really drives me crazy now. If you’ve ever inspected a single element in Chrome dev tools or Firebug, you’ll know why. Meyer’s style reset, fills your inspector window thusly every time you click on an element:
  
  This clutter will show up for every single element you inspect. It’s not a huge deal, and you can remove the style reset and roll your own, but I still wish it wasn’t there to begin with.
• Too spartan out of the box. I’ve always found Toolbox and Underscores to be way too spartan from the outset:
  While I understand that this is meant to be just a starting point, I still don’t find it warm and cosy when I start a new project.

Bones

Bones is a hot new theme from Eddie Machado. It’s much more opinionated than Underscores and comes with a few more things under the hood. Before we weigh out the benefits, I need to disclaim up front that I’ve not yet used Bones for a project, so all of the opinions below are just wild speculation. But let’s do it anyway:

Pros:

• Responsive. Bones has a responsive grid baked right in
• Looks good from the get-go Bones isn’t spartan from the start. It has a basic layout ready for you, and overall feels a little better than Underscores does. Sure, you’re still going to undo all of these starting points (the pink headings, etc) but it still feels better to me to start with something out of the box:
  
• Normalize.css. If you’ve never used Normalize.css from Nicolas Gallagher and Jonathan Neal it’s worth a look. It does the job of resetting quite well, without cluttering up your inspector window.
• LESS/SASS from the start. Here’s where the opinionated part comes in. I love that Bones insists that you should be using a CSS pre-processor (and you should) and makes the two most common options available to you
• Verbose documentation. Some might find this level of documentation to be overkill, but I think it’s going to be helpful to leave it in for at least the first few projects. Machado crams a lot of WordPress know-how into each and every line.

Cons

This is the part where the comparision goes off the rails a bit. Given that this is really a setup post and not a followup, and that I’ve not actually used Bones yet, I can only list a few cons that come to mind when poking through the project’s files and folders

• Modernizr. I don’t use modernizer. At the moment, it feels like this will add unneeded overhead for me. I have no idea. I might use Modernizr for every project henceforth, but for now it feels like it might get in the way
• No get_template_part. Bones doesn’t use the get_template_part pattern, instead loading a lot of functionality into index.php. This doesn’t mean that I can’t do things the way I like, but is still not ideal for me.
• Bones is opinionated. I’m not actually sure yet if this is a pro or a con. Opinionated code is great for beginners and people who have the same ingrained opinions. It will be interesting to see if my Machado and I do things the same way. It will be very interesting to see if I come around to his way of thinking if we don’t!

So there we have it. Underscores and Bones in a tête-à-tête. Results to follow!