I’ve been mulling over and debating whether to write this post for about a week. It’s a response to this post on ThemeShaper. In the post, Fränk Klein, in no uncertain terms, explains why using Bootstrap with WordPress is a bad idea. Being the author of a WordPress theme that is based on Bootstrap, as well as a Pluralsight course on that very subject, I felt I had to say something.
Let me start off with a bit of backstory. The ThemeShaper blog is written and maintained by the Theme Wrangler team at Automattic, the company started by WordPress co-founder Matt Mullenweg to provide WordPress-related services. I have the utmost respect for Automattic’s Theme Wrangler team — in fact, up until relatively recently I had considered it one of my “dream jobs” — who are responsible for creating themes for WordPress.org and WordPress.com that are used by thousands (if not more) of blogs around the world. They are also responsible for starting the _S project, a starter theme that is encouraged to be used as the base template for all WordPress themes. Their work is the standard by which all theme developers should hold themselves to and ThemeShaper is like having a direct line into their collective brains. I’m also all for companies taking a strong stance on ideas that are potentially controversial — often companies and company blogs will pussyfoot around, or completely avoid potentially divisive discussions like this.
I just happen to disagree wholeheartedly with this particular post.
“Bootstrap is the wrong tool for the job”
Bootstrap was created at Twitter as a tool for back-end developers to easily create interfaces for their applications…it’s the wrong tool for a WordPress theme: the front-end, or how the site looks…is all that counts.
Obviously this is a matter of opinion. Bootstrap is a tool. It’s not like using a screwdriver to open a can of beans. It’s more like finding the can opener attachment on a swiss army knife. Fränk elaborates that Bootstrap was originally built with back-end interfaces in mind. That may have been the original intent, but surely you’re not going to argue that the Carousel component is for admin interfaces? The reason why I, and most other theme- and front-end developers would choose to use Bootstrap as a framework to build a theme on is because of the mobile-first approach to responsive design, something that has been pretty widely accepted as a best practice for building sites that work on all devices. Bootstrap provides a head start for responsive design much in the same way that _S provides a head start in theme development. No, it doesn’t mean you get a responsive site out of the box without needing to change anything, but it gets you pretty close.
“Bootstrap does not do things the WordPress Way“
Bootstrap…has its own approach to how the HTML is structured [that] does not fit well with what WordPress provides by default…developers have to take extra steps and write additional code to modify WordPress’ behavior to the fit how the framework works. A good example for this are navigation menus. Instead of using the output of
wp_nav_menu(), developers have to write Custom Walker classes that change the HTML output by the function so that the Bootstrap CSS and Javascript can be used.
This is something I’ve had first-hand experience with. Yes, Bootstrap has its own way of doing things and yes, you need to use a custom walker class to get the menus to work using Bootstrap’s styles. In fact, my course on Pluralsight focusses a lot on getting Bootstrap to do things in the WordPress way. But just because Bootstrap expects a certain kind of approach to marking up your HTML doesn’t mean that a theme or site can’t still be done in the WordPress way. In fact, that was kind of the point of my course; getting WordPress and Bootstrap to play nice together and the things that I learned while trying to pursue that goal.
And I’ll go one step further to ask What’s wrong with custom walker classes? If it was something that wasn’t the “WordPress way”, why is there documentation on it? Unlike some other core functions that explicitly state that they are not intended for theme or plugin developers, there’s no such note for the Walker_Nav_Menu class and if this is something that theme and plugin developers should avoid, it’s the first I’ve heard of it. On the contrary, there are lots of great tutorials for creating custom walker classes. And digging into these kinds of functions helped me learn more about how WordPress handles navigation. Isn’t part of the point of open source in general, and WordPress core code specifically to encourage this kind of learning? Digging in, getting your hands dirty, and figuring out how stuff works is what open source is — and should be — all about. wp_nav_menu is a great function. I love it. I use it a lot. But I also love the fact that I can create my own custom nav if and when I want to. That’s okay, too.
“Bootstrap is bloated”
Tom McFarlin wrote a great post following the ThemeShaper post called “Everything is Bloated, Nothing is Good.” In it, he points out that pretty much every framework has been called “bloated” at one point or another, including WordPress itself. WordPress comes loaded with a ton of javascript libraries, many of which I may never use on a given project. Does that mean that WordPress is inherently bloated?
I don’t think so. As a developer, I am happy and encouraged by the fact that these libraries exist and that I can call them from core rather than loading them into my own theme or plugin. It’s not bloat, it’s giving me options. Similarly, Bootstrap has a lot of stuff that I might not use on a specific project. But it also has a lot of things that almost every project will probably use. That’s the point of Bootstrap. Just like it’s the point of WordPress core to include the functions, classes and libraries that almost every site will probably use. And, as Tom points out, most modern frameworks — Bootstrap included — allow developers to download a custom build. Meaning you can filter out the bloat if you want.
Museum Core was built on Bootstrap because I built it to be a framework for WordPress sites and themes. It is loaded with the things I need to rapidly develop and deploy responsive WordPress sites, with built-in customization options for users to enable them to customize their site using the theme customizer controls. It includes those javascript components from Bootstrap that it’s using and excludes those that it isn’t. Any “bloat” it may have comes from the CSS (which, when minified, does not produce a large overhead and enables users and developers familiar with Bootstrap to also use Bootstrap classes in their site) and a customized version of the FontAwesome icon pack which had many of the icons that weren’t being used (and probably wouldn’t ever be for most sites) removed.
Don’t be so quick to write off something as being bloated simply because it doesn’t align with whatever philosophy, vision, or decision that you personally have for a project. Just because something includes an option (or set of options) that you don’t use doesn’t mean it’s generally bloated.
— Tom McFarlin [source]
“Bootstrap does not encourage great design”
I think any designer who uses Bootstrap will take offense to this statement. I’m not going to claim that I’m the best designer. But I will say that it’s highly limiting and presumptuous to say that “great design” cannot be done with a Bootstrap framework. The post goes on to explain that this is due to Bootstrap’s twelve-column grid system.
One of the most popular features of Bootstrap is the twelve column, fully responsive grid system. By adding classes into the HTML markup, developers can create websites that react to every screen size…Unfortunately using a predefined grid is the wrong approach to achieving a great design.
It continues to rail on grid systems saying that they are “without proper proportions or harmony.” I find this to be very interesting and a little puzzling. Grid systems have their root in print design, but they go back far further than that. The Golden Ratio, used in mathematics, architecture, art and design — as well as being found in nature, in the form of fractals and patterns in living organisms — is a kind of grid. Grids were used by the Greeks, a grid was used by Leonardo DaVinci in his Vitruvian Man.
I’m not sure that I buy the idea that a grid — just by nature of being a grid — leads to bad or “mechanical” design. If that was truly the case, there would be no beauty anywhere, because grids are everywhere, not just in web design. Using Bootstrap’s grid, or not, does not mean you can’t create something aesthetically pleasing. All the grid does is make it easier for a designer to place objects on a page — in much the same way that this would be done in print design, placing cut up columns and scraps on a grid of boxes. A grid system in web design is there so you have an unchanging set of base rules for layout that you can use in a variety of different combinations. And while the Further theme that ThemeShaper uses currently on their site (which is a cousin to the free TwentyFourteen theme available on WordPress.org) doesn’t explicitly use a grid, that doesn’t mean that a grid couldn’t have been used to get the exact same result.
I’m not going to toot my own horn too much, but besides this blog, these are a few examples of themes that were built using Museum Core (and therefore, the Bootstrap grid) as a parent theme:
Except for both having a center column for content, the themes are (I think) very different in look and feel. And I believe that both are visually appealing in different ways. Neither seems mechanical to me, or lacking whimsy, yet both were built with a Bootstrap-based framework and grid.
The final irony of the Bootstrap-is-bad-because-grids-are-bad argument is the example of what to do instead which immediately follows the tirade on grids:
That’s right, the “better approach” uses…a grid system:
Nothing is perfect. Nothing.
The article concludes by, in really rough and ambiguous terms, discussing how each project is different and you should approach it based on what works for that particular project. I agree with this. The ideal in design is to build the design around the actual content that is going to be on the site. But, this is only really possible when you are tailoring a theme to a specific site and content. It’s not possible to have a vision for WordPress theme and know — with absolute certainty — that someone isn’t going to try to use your theme for something completely different or what the content on that specific implementation is going to look like. As such, you need to build for all possible cases. Museum Core was built — like Bootstrap — as a generic framework that other developers and users could hook into and use and expand on. Aside from the possible “bloat”/”too much” argument, I see absolutely no reason why using Bootstrap is any different than using a starter theme like _S, something the ThemeShaper article goes on to advocate.
I won’t vouch for every Bootstrap-based theme out there and I’m not going to say that having Bootstrap in the description is necessarily a selling point. It is, however, a point. Something that I as a developer can look at and say “oh, good, I know Bootstrap, so I know how to manipulate this theme.” When a theme is built with Bootstrap classes, I know I can flip over into the HTML in a WordPress post and create a layout that works — something I do frequently on my own sites and something I would need to dig through lines and lines of code to be able to do with the theme that ThemeShaper uses or else use inline CSS styles (generally regarded as the worst-possible thing you can do as a front-end designer).
Being able to tweak the design and layout quickly and without having to constantly refer to the source or add in a lot of my own custom HTML and CSS is what having a Bootstrap-based theme means to me and there is value in that.
Leave a Reply