Since its release in 2011, Bootstrap has quickly become the most popular front-end framework on Github. This popularity also has an impact on the world of WordPress themes, with authors using the framework during development or even releasing themes that feature Bootstrap as unique selling point.
This is surprising, because Bootstrap is not a great fit for WordPress theme development.
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. Before Bootstrap, various other libraries were used, which resulted in inconsistent and difficult to maintain interfaces.
So Bootstrap was created with a precise goal in mind, and it continues to develop according to this initial vision for the project. It was created so that developers could focus on back-end code and quickly iterate without having to worry about the front-end.
This is why it’s the wrong tool for a WordPress theme: the front-end, or how the site looks with the theme activated, is all that counts.
Bootstrap does not do things the WordPress Way
WordPress facilitates theme development by providing a set of functions to be used in template files. By leveraging the HTML output of these functions, developers can write efficient and clean code that works with a variety of content.
Bootstrap on the other hand has its own approach to how the HTML is structured, and it does not fit well with what WordPress provides by default.
As such, 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 approach results in more code and as such is less efficient, results in more maintenance and development time and also does not benefit from the enhancements made to the Core functions.
Bootstrap is bloated
Framework code can never be as efficient as code written for a specific purpose, since frameworks build up from general cases to more specific cases and add bloat in the process. Often multiple CSS classes need to be added to HTML elements to achieve a desired visual result, along with the necessary CSS.
What adds to this problem is that often times, not only the CSS code necessary for the theme’s design is packaged, but the entire framework code.
Bootstrap does not encourage great design
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. The major problem is that you are designing from the outside in, shoving content into predefined boxes. The result is designs that have a rigid and mechanical feel to them, without proper proportions or harmony.
The one-size-fits-all approach also ensures that the theme you’re designing does not adapt to any constraints like image dimensions or line length. Whether you’re using a narrow sans-serif or a didone serif that needs room to breathe, the grid stays the same. The result is often bad legibility and nonharmonic typography.
A better approach
Every great theme design starts with a vision. What is the purpose behind the theme you’re designing and who do you envision using it and it what context?
This will inform you about the constraints that you have to work with. Designing an image heavy portfolio theme is a different challenge than creating an optimal experience for a magazine theme featuring long form articles.
Once you have set on a vision, you then start designing from the inside out. Get some sample content for a couple of test posts and then start designing the experience of consuming that content. You’ll see that once you focus on the content first, you can build out the remaining design elements around it and achieve a harmonic result.
On the technical side, use a starter theme that provides you with enough markup to quickly start diving into the presentational markup, without being overly opinionated about the design. Use libraries and code snippets to reduce development time. The default themes that ship with WordPress are usually a good resource for extracting code snippets.
ThemeShaper 
36 responses
The “framework” landscape is quickly changing thanks to tools like Sass, Compass, and Foundation, where you can include and use only the modules you need. The compiled CSS can be much cleaner than simply loading everything from something like Bootstrap.
Using the @extend method, you can easily attach grids to CSS selectors without applying presentational classes to markup, which is always a bad idea.
Oh man you said it! I really really do not like presentational classes!
I find it very helpful to build a custom WordPress CSS selector library and gather property presets over time. It’s much easier to delete a text-shadow and adjust a padding value than to rewrite the whole
.buttonclass every time. Having custom style presets at hand still leaves you flexible enough to design from the inside out imo.It’s a good starting point for people who don’t have a whole lot of time. I used it pretty extensively early on, because I knew that no matter what functions people required later, it would be built in already, which allowed me to move pretty quickly. As time went on, and I learned more, I built more and more of the site myself – eventually I outgrew it and built much leaner sites that I didn’t have to take time to override and restyle. Suppose that’s why it’s called bootstrap – it gets you there with little effort, but eventually you start cobbling your own boots!
Some good advice here. You make some good points. Thanks for the reminder. It’s worth mentioning that Bootstrap has both LESS and Sass support, and doesn’t require use of the default class names or even the grid or other modules at all. Its misuse is the biggest problem. I agree though, that it is too heavy handed for a lot of things.
unopinionated starter themes, libraries and code snippets, borrowing from the default… These were things I tried -before- settling on Bootstrap / _tk for a device-agnostic, actively-developed framework.
Bootstrap sprawls, and it’s a bit of a tangle without a preprocessor, but everything else I’ve tried ends up requiring patchwork or paid solutions.
Can you suggest any specific alternatives that provide solid responsive elements and a usable grid? People use Bootstrap for these features, and maybe the pretty buttons.
Whether the grid is a valid tool for laying up web content seems like a topic for a different article :oP
Your article makes sense. Joomla 3 adopted the bootstrap framework and take a look at the default theme that ships with Joomla: http://www.joomla.org/3/en This is a good example of a design with a “rigid and mechanical feel, without proper proportions or harmony” (a nice quote ;-).
I quite like bootstrap and have used it in one WordPress theme and a couple other sites.
I didn’t really think about it until reading this but you’re right, I likely spent more time working around the different ways WordPress and bootstrap work then if I had of skipped bootstrap all together.
“Framework code can never be as efficient as code written for a specific purpose, since frameworks build up from general cases to more specific cases and add bloat in the process.”
THANK YOU. I’ve been saying that for a while now when any type of framework attempts to sell on efficiency. I had to build my own WordPress framework to realize it’s bloat no matter what in comparison to focused code. And of course, this applies to frameworks in general. Good read.
Thank you for this. One reason I’ve never liked seeing “built with {framework}” on a lot themes. I feel like I’m going to be getting an entire Nascar garage when I only really want is a few allen wrenches and a flat-head screwdriver.
So what about using the Zurb Foundation framework instead? Does it suffer the same issues?
Zurb suffers from the same premises as Bootstrap. It’s a (less) bloated jump-start framework, better suited for prototyping than building final products. It’s not necessarily Bootstrap in particular that’s the issue, rather the idea of including an entire front-end framework when your code and assets should be catered to your theme.
Hi Mike,
when was the last time you used foundation if you ever used it?
We’re actually using parts of Foundation on our site, Array. We’ve removed much of the code and taken only the bits we need. It can be a great tool if you wield it right!
I disagree with that comment on so many levels – each to their own though I guess 🙂
Wow, I really disagree with a lot of this. Of course some of it is absolutely true, like the fact that a whole framework adds bloat when only part of it is used. But using frameworks and starter themes saves tons of time and in my opinion is almost like pulling in expert help each project.
_S is described as a thousand hour head start I believe, and the one I use now which seems very popular (roots.io) is based on Bootstrap. Adding a bit of “presentational classes to markup” doesn’t really bother me like it does others I guess. And you can do a custom build of bootstrap with just what you need.
For example, I’ve never used out of the box bootstrap styling for buttons in a custom design, so I don’t need to include those styles. And being that our designer has a firm background in print and does incredible work, I can safely say no job done in the last year by my team has looked “rigid or mechanical”.
No reason to get lazy and not style something original, and no reason to re-invent the wheel for a mobile first cross device layout for every project either.
I disagree, bootstrap is not a bad fit for wordpress themes, it provides a nice foundation to build upon covering lots of elements that most designers/theme developers don’t even bother to style (e.g. forms for instance). Also its CSS with a preprocessor allows you to easily cut any “bloat” by not including things you don’t need. Bootstrap also provides a wonderful “mobile first” responsive approach out of the box with some of the pain points already solved for you. With the huge increase in mobile and tablet traffic more and more themes need to start offering responsive out of the box.
The whole “presentational class names” is a terrible argument, classnames are intended for styling purposes and having a good classname to make elements consistent outweighs having a custom “semantic” class name for every element on the page.
As a developer on large scale projects I can attest to the wonderfulness of having a foundation much like bootstrap.
Tom McFarlin has written what appears to be a response to this article, though he doesn’t say so explicitly.
I agree with your broad point that Bootstrap wasn’t intended for the kinds of uses it tends to be put to today. The majority of its controls and components are more appropriate for web apps with a lot of user interactivity, which doesn’t fit most WordPress themes.
That said, I think most of the problems you raise come down to people using Bootstrap poorly, rather than the framework itself (or, as you seem to indicate at the end, frameworks themselves). This has more to do with the wild popularity and ease of use of Bootstrap. A lot of people are using it to do things that they otherwise wouldn’t know how to do.
When we see a site built with Bootstrap and think “poorly done”, it would probably be “pretty terrible” without Bootstrap. (The same effect is in play with WordPress, too. We accept that a whole bunch of terrible websites are made with WordPress. It’s just part of being popular and easy to use. It doesn’t reflect on what WordPress is capable of.)
I stopped using the full Bootstrap package in my own projects a while ago. But I kept the grid system and the drop-down component for navigation menus — both of which come in for criticism in your article. I’ll tell you why I still hold onto them and why I think it’s a good choice:
1. The grid system. Yes, relying on the grid system for every component is usually the wrong approach for a design. But unless you’re making an artsy portfolio/blog theme, you’ll have to roll your own grid system whether or not you call it such. Bootstrap’s really isn’t that heavy and it’s backed up by a lot of research about breakpoints and device compatibility. If you use a CSS pre-processor, you can use extends to avoid extra HTML markup if you’re that concerned about a few kbs. I’m not into code golf.
2. Bootstrap’s drop-down component doesn’t fit with WordPress’s navigation menu very well. It only supports 2-level hierarchy! But it’s worth remembering that Bootstrap has a mobile-first philosophy. That philosophy, which goes beyond just touch-support to encompass simplicity in interaction, matches mine, and I believe limitations like this are good.
But what makes the component really valuable to me is that I can count on it for wide device compatibility, because it’s in such heavy use that it’s well tested. I can’t afford to test on dozens of devices myself, so going with a framework that is widely used scales the compatibility of my code.
This is an often under-appreciated aspect of frameworks. Good ones like Bootstrap can show you how to do things well, because they’ve been exposed to so many more problems than you have. And because they’ve often been written by people who are better than you at what you do. If you’ve leveled-up your front-end skill enough to move past a framework, that’s great. But that’s still an important ladder to get people on. “Do it yourself” is appropriate when someone knows what they’re doing really well. Otherwise it’s often a recipe for disaster. (Remember, that’s one of the reasons why we always say “do it the WordPress way”!)
“bloat” – easily remedied by not loading things you don’t need. Bootstrap gives you an awesome way to piece together only the things you are actually using in both CSS and JS. WIth what you do need, deal with it properly, and you won’t notice a difference, especially over any other framework. Based on your post, there is never going to be a “good framework” for WordPress, that isn’t explicitly built for WP. You make the assumption that WP is the de-facto best way to code things.. but it isn’t. Using walker classes and more advanced functionality to code better outputs allows you to use any framework.. and if coded properly, really is NOT an expenditure overhead, nor do you have to spend too much time maintaining it.. because overall, you code it well once and it’ll just work..
Also, if you wanted to use wp_nav_menu, you can.. using their default output on HTML the only thing you’d need to change is the sub-menu class name, which can be done with a walker.. or a simple jQuery command.. if you even need a drop down. with wp_nav_menu you can remove the container, add a new class to the and the B.S. ‘s don’t have any extra classes (although you can still easily add them in with wp_nav_menu)… check out the code again – http://getbootstrap.com/components/#navbar
Totally agree with this post. I see so many people always use Bootstrap everywhere and call it a theme feature. That’s so wrong!
This post should be read by all theme developers!
What is a Framework?
frame·work
a basic structure underlying a system, concept, or text.
I find Boostrap anything but the framework and ZURB is not far behind that either. They should be called UI Toolkits instead.
Framework works to assist, not to dictate our projects.
Great article Fränk and thanks for bringing the subject.
Wow. Really? I don’t know where to begin, there’s so much that’s wrong with this article.
If you have all the time in the world I can understand your argument, but for those of us who have to balance, work and family, any tool that speeds things up for me is a good thing.
Why write a walker class for Bootstrap when others have. Let’s just use theirs:
http://lmgtfy.com/?q=wordpress+bootstrap+walker
Why write a Bootstrap WordPress theme when others have. Let’s just modify theirs:
http://lmgtfy.com/?q=wordpress+bootstrap+themes
I realize this article is about your perspective on Bootstrap, but did you write an article on the bloat in WordPress, and how WordPress should be rewritten into an MVC architecture and separate it’s code from the UIs?
> Despite this, for individuals weaned on an ideology where “semantic HTML” means using content-derived class names (and even then, only as a last resort), it usually requires you to work on a large application before you can become acutely aware of the impractical nature of that approach.
http://nicolasgallagher.com/about-html-semantics-front-end-architecture/
Everybody pile on board … Oh wait …. Now the boat is too full and it’s sinking …. Everybody off!!!
Development is too damn fickle.
> Use libraries and code snippets to reduce development time. The default themes that ship with WordPress are usually a good resource for extracting code snippets.
Why does each year’s default theme re-invent both the html and css? After all these years of creating themes, shouldn’t it be iterative? If we’ve got the same semantics (posts, pages, galleries, etc), why do we even need to touch the generated code for each theme release. At this point, shouldn’t we only concern ourselves with css then?
Why does the 2013 theme change so much compared to the 2012 theme? For a genetic theme, the semantics should be the same, so we should only need to change the css, right?
There was a thread in the WordPress forums about what to do with the TwentyFourteen theme. There was a push from a fair number of people to have it be done strictly with CSS. But ultimately, like they had done in prior years they instead chose an existing theme and retooled it on top of _S. I agree that it would be better if they incrementally added features each year, but instead they actually drop previous year’s features. I think they are actually worried about “bloat” just like the author of this article is.
What if I’m not a hobbyist and I need to develop cross-platform (I.e WordPress, Drupal, Shopify, Squarespace) themes/templates where there are a number of front-end and back-end developers? You’re saying it is better to conform to the platform instead of developing platform-independent modules (html/css) that can be tested once?
I think it’s much easier to code a walker class for your already-tested menu module, than to create one-off css and then retest on IE, Chrome, Safari, iOS, Android, etc.
“Nothing can be generalized.”
Every project, theme, framework, tool, plugin, CMS has their advantages and disadvantages.
I would go for Genesis/Thesis if I want to quickly build something taking care of the underlying code’s quality in terms of security, extensibility and not to forget, SEO.
I would go for a custom theme using _s sometimes.
I would go for Boostrap/Zurb if I don’t want to deal with checking and fixing a lot of mobile responsive design errors. And don’t want to mess around with grid layouts for display featured posts or portfolio items.
It all depends on us to pick the tool that fits our requirements best.
This is exactly where SAASS/LESS come into play. You don’t need to include the whole Bootstrap code base, just to components you need. One some projects I’ve literally only included the grid and few other small components. Unfortunately, few people actually realise that SASS/LESS is present in these frameworks, hence including the entire library and making statements like “Bootstrap is bloated”
As a developer, I’d much prefer to inherit a site made using a well tested and written frontend framework.
Thanks for this. I tend to agree from personal experience. I had been using Zurb Foundation to speed up development but it does involve a lot of overhead and I found I spent a lot of time tailoring the framework. It was much easier to use Sass/ Compass for UI elements and javascript as needed. I like the look of Bootstrap but it does lead to a lot of sites that look the same and adding extra divs (although not strictly necessary with Bootstrap) can make a theme unwieldy and difficult to customise.
I found this article interesting and thought-provoking. I have recently developed a series of WordPress themes that are based on _S and Bootstrap. I generally agree that the issues your present have some validity, but I wanted to share why I made the decision to go this route.
_S is the basis for all “core” WordPress themes, like TwentyTen through TwentyFourteen and beyond. So most people know how it works already.
For the very same reason, Boostrap is a good fit because so many people are familiar with it
For me as the theme designer, I know Bootstrap is heavily tested and bugs are continually being fixed.
With recent design trends toward a simpler or “flatter” style, users want to be able to spruce up their content. Of course with images and video, but also using columns, icons, progress or “skill” bars, collapsible content, etc. Bootstrap handles all that.
By using Bootstrap for user’s content, they can not only easily switch to any of my themes, but switch to any Bootstrap theme or even use a Bootstrap plugin on non-Bootstrap themes. Redoing all your content when changing themes is a nightmare.
In addition, I wanted to comment on a few of your specific points.
Bootstrap can easily be setup to use only the features that you want. I also changed the color palette, the look of buttons, font sizes, etc. using their customizer so that I don’t have to add bloat to overwrite those things.
The difference in menu philosophies requiring a custom nav walker is really the only significant difference between how WordPress and Bootstrap work. The only other “tweaks” that I’ve had to make was adding a little CSS to style some WordPress specific things they way Bootstrap styles them, such as input buttons and the currently active item. In fact, I would argue that WordPress should add a few additional parameters to wp_nav_menu to allow more control over CSS classes applied.
This article should just be called “Why I Don’t Like Frameworks”. That’s fine, but don’t go so far as to say it’s bad for WordPress themes. The “code written for a specific purpose” argument is pretty awkward to make when you’re talking about designing mass-use themes for a general-purpose CMS.
I usually use Foundation (I like the structure a little better than Bootstrap) and it’s terrific once you get a handle on it and know how to use it properly — you save time and don’t have to include the parts you don’t need. The only practical example against frameworks I can see in your post is the issues you run into with nav menus, which, OK, is one annoying thing but that’s why walkers exist.
Totally agree, when it came out it was all the craze, but I later realized that I had to remove so much stuff from bootstrap that It was easier to just write my styles from the ground up when building WordPress themes.
It’s still my favorite css framework when it comes to building web applications though, because I get lazy sometimes 🙂
For a very specific website or web app, I agree. However, when it comes to developing themes for WordPress, especially with today’s “flat” style being popular… users want and need to be able to add lots of variety to the content itself. So while I could strip out a lot of what Bootstrap features I don’t need, users are going to want it all. If the theme is lean, then they’ll add shortcode plugins which come with all their own PHP and CSS bloat as well. And in that case, its all plugin-specific PHP and CSS, so why not have more themes and plugins just support Bootstrap.
I’m not saying Bootstrap is the be-all-end-all for every situation, but this article is specifically about it being bloated for WordPress themes and users are demanding the ability to use a lot of different content types and Bootstrap has it, everyone already knows it, its well documented, if more themes use it then the easier it is to switch themes.
I agree at some point but I really like to use Boostrap. I use it most of my latest wordpress development projects.