At Reaktiv Studios we don’t always get to choose what kind of CSS we use in our projects. But when we do, we often turn to Bootstrap.
We’ve found it to be predictable, modular, well documented and easily shareable across the team. You may already have an opinion on Bootstrap, but it also might have been a while since you’ve used it. In the last year or so, there have been some pretty incredible changes to the framework.
Bootstrap Version 4
Bootstrap got its start almost a decade ago, when it started out as an internal CSS guide at Twitter. It slowly evolved into an extendable, modular CSS framework used in prototyping and production sites. Over the years it’s been criticized for a lot of things, from contributing to the sameness of web design to CSS code bloat. But with the release of Bootstrap 4, a lot of those criticisms have been addressed. It’s time to give Bootstrap another look.
Bootstrap version 4 was officially released back in January, but in truth it’s been in alpha and ready for production for over a year now. It’s a massive rewrite of the library. The code’s been ported over from LESS to SASS. It includes a brand new set of helpful utilities. And it’s more customizable and modular than ever before.
When we were building our own starter theme, the improvements in Bootstrap 4 got our attention.
I’ll start out with a disclaimer: Bootstrap isn’t always the right choice. There are many options out there, and sometimes a bit of hand rolled CSS is really all you need. So before you start leaning on it, ask yourself a few questions.
- Are you going to actually use the modules included in Bootstrap?
- Do you need a solid, responsive grid?
- Does the design call for a standard navbar, modal window, or alert boxes?
If you’re building some unique and off-script design, Bootstrap won’t have what you need and something more custom will likely do the trick. Bootstrap is, at its foundation, a predictable and reusable framework. If your design calls for one-off templates and distinct landing pages, then maybe it’s best to look elsewhere. Bootstrap calls for some pretty specific HTML markup. If your site or applications depend on third party services or plugins with inflexible HTML, you may need to create your own CSS to hook into those classes.
If you managed to get past these questions, and it feels like your project still meets the criteria, there are a few things about Bootstrap that I find to be endlessly useful.
When I say modular, I truly mean it. You can use as much (or as little) of Bootstrap as you want. The codebase is broken up into a series of component files, things like typography, a carousel, a 12 column responsive grid, alerts and modal windows. If you’d like a full rundown of components used in Bootstrap, I’d recommend reading through the incredibly thorough documentation.
I typically think about Bootstrap components in terms of base styles and components. Base styles include, well, the basics, the foundation that sets up your entire cascade. Things like some typography and heading classes, a responsive grid, and a homegrown CSS reset based on Normalize called Reboot. Base styles don’t change too much from project to project, and their footprint is fairly minimal. In Bootstrap, they’re also fairly customizable, which I’ll get to in a moment.
Components are the various modules you may or may not have a need for, like buttons or cards or dropdowns or a navbar. The more of these you add to your project, the more your codebase will grow, but it’s rare that I actually need to pull in everything. That’s what makes Bootstrap’s move to SASS and it’s modular architecture so appealing.
Individual components are brought in through a series of SASS imports. If you don’t want to include a component, remove the `@import` rule and you’ve taken down the size of your stylesheet. In each project, we include our own custom bootstrap.scss file that selectively imports just the components we need. It’s not uncommon for us to just use a handful, and leave everything else on the cutting room floor.
In the old days, the way a lot of people modified Bootstrap styles was to include the entire codebase, and then add additional rules for the classes to override it using specificity. This led to duplicate code that was hard to follow and seemingly never-ending bloat.
Now, everything in Bootstrap is customizable. In fact, there’s hardly a line of CSS that’s not configurable. And the way you customize things is using SASS variables.
Bootstrap has its own SASS variables file. But rather than changing that file manually, you can import the whole file into your project, and then include your own custom variables file. Bootstrap variables all use the `!default` flag from SASS. That means if another file defines a variable with the same name, it will override the value, even if it was imported first. In our projects, we typically import our own variables file in the project first, and then load the bootstrap variables file right after.
@import "custom_vars"; @import "vendor/bootstrap/variables";
Our custom variables file only includes rules that are specific to the project. Everything else defaults back to Bootstrap’s settings.
In general, you should try to avoid overriding Bootstrap with another CSS ruleset. Instead, you should customize modules and components by tweaking a variable or two. There really are variables for everything, from base fonts to whether transitions should be turned on to a list of grid breakpoints. If something in your design doesn’t fit with Bootstrap’s default output, I’m willing to bet there’s a variable that will make it work.
Of course, each project will require a bit of custom CSS. But we’ve actually been able to keep that as low as under a hundred lines or so in some projects simply by making sure all of our variables are set properly.
Utility classes are still a fairly new addition to the Bootstrap ecosystem. They’re a collection of helper classes for defining things like margin, padding, and responsive behaviors. Frameworks like Atomic CSS are wholly dependent on these types of classes, but I find that Bootstrap includes just what you need, while still depending on a modular architecture for most components.
Utilities have really changed things for how we write CSS. I don’t know about you, but I’ve found myself coding the same `margin-bottom` or `font-weight: bold` definitions dozens of times throughout a project. I’ve heard Dave Rupert talk about these kinds of styles as the “brick and mortar” of a CSS codebase. Styles that glue and hold together different modules, but aren’t specific to the module itself.
With Bootstrap, if I want to add a bit of margin to a heading, I could just add the class `mb-2`. Need a bit more? Try `mb-3`. Need a bit of a box shadow? How about `shadow-sm`. The class names might seem strange at first, but once you learn the conventions, you’ll find yourself building out designs much, much more quickly. Whenever I need to add a bit of space, or construct a grid, or switch a module to flexbox, I reach for a utility class that can do it for me. It keeps your designs consistent and reusable. If I code up a design and hand it off to another developer to work on, I know that they’re going to use exactly the same utilities. I’m not at all exaggerating when I say this has been a major boon for our productivity.
Quick note, make sure to check out and define your spacer and grid variables before using utilities.
Bootstrap has been in development for over a decade. It’s accessible, well tested across browsers, and deals with edge cases you’ve never even thought of. Linus’s Law, “given enough eyeballs, all bugs are shallow,” is very much in play with this framework, and I feel confident that when I use a bit of code from Bootstrap it’s reliable in every environment and runtime. That’s the same thing that probably drew a lot of us to WordPress and open source in general, and it has incredible benefits for Bootstrap.
How We Use It
Here’s the nitty gritty. When we include Bootstrap in a project, we download a fresh copy in a separate `vendor` folder. There are all sorts of dependency managers you can use to automate this. We have a customized Gulp process to help out. In my experience, just downloading all of the SASS partials into a single folder is usually enough.
Next we set up the imports for Bootstrap, which is derived from Bootstrap’s own imports file. The only required modules are the Bootstrap variables file, functions, and mixins. You can selectively include the rest of the library based on your needs. Remember, you neither have to nor should include everything.
The final step is to create our own custom variables file. This includes just a list of variables unique to your own project, which should override Bootstrap defaults. This should be imported into the main SASS file at the very top. Whenever we need to change a rule we copy it from Bootstrap’s variables file into our own and change the value.
Our custom CSS is all imported into the same file, which gives us a single stylesheet that includes a mix of (mostly) Bootstrap and our own, hand-rolled styles.
Looking to the Future
It’s possible that over time, things may change. Browser makers have given us a number of layout tools, notably CSS grid, that make some of Bootstrap’s functionality obsolete. But if Bootstrap continues to evolve alongside CSS specification, as it did with Flexbox, that won’t be an issue. Bootstrap can still abstract away some of the more complicated bits while giving us even and reusable styles to plug into projects.
Then there’s Gutenberg, which I’m sure is on all of our minds. Gutenberg is interesting because (out of the box at least) it prescribes certain markup to the blocks that it output. This HTML is not compatible at all with Bootstrap classes. Would it be possible to modify Gutenberg to output markup that works with Bootstrap? Certainly, but I still think Gutenberg will change the way we think about CSS in WordPress themes and force us to get more creative with how we structure styles. I think that’s a sentiment covered fairly well by our own Cory Webb and what he’s been calling the Gutenlook.
Still, I think if there’s one thing that Bootstrap has proven, it’s a willingness to adapt to the changing environment of CSS. There aren’t too many software projects that have been going strong for over a decade. When you look back to the kind of CSS that was possible then to now it’s astounding how far we’ve come, and Bootstrap has managed to keep pace with each new development. Basically, until proven otherwise, I’ll be turning to Bootstrap whenever I can.
Filed under: General