A few weeks ago on The Nitch Podcast, I'd made a comment that I'm not a big fan of Bootstrap, but had decided to use it anyway for a side project I’m working on. Recently, one of our listeners who'd just heard the episode emailed me to ask a few questions:
- If I'm not a fan of Bootstrap, why did I decide to use it anyway?
- If Bootstrap isn't my go-to, then what do I use?
- If I don't use a CSS framework, don't I often find myself needing to duplicate the functionality that one would provide?
These are interesting questions, so I thought i would answer them here instead of in an email. Before I get into that, though, let me explain my stance on Bootstrap (and CSS frameworks in general).
I don't love Bootstrap. I don't hate it, either.
Jon and I talk a lot about defaults and for me (and also for him, coincidentally), Bootstrap isn't one of them. There are times when it makes sense and times when it doesn't. Like most frameworks, libraries, and languages out there, it has its benefits and its drawbacks, and they are often highly subjective and personal.
- It often unnecessarily increases page weight. - Bootstrap in its entirety can be a large download, especially on mobile, and many people using Bootstrap aren't leveraging anywhere near all of its functionality, so a big chunk of that code is simply unnecessary. If you're not doing a custom build to get rid of what you don't need, then you're wasting the visitor's time.
- The markup that Bootstrap requires isn't semantic. - With pretty much every CSS framework out there, you end up with a lot of "DIVitis" and non-semantic markup serving as wrappers, containers, and elements that exist solely to be presentational. This again increases page weight. It makes reading the code more difficult, and it can cause issues with some assistive technologies.
- Bootstrap makes a lot of assumptions for you. - Its built-in grid system offers a lot of flexibility, but you're still limited to working within its constraints, or suffer the consequences. Now I'm not opposed to opinionated software (otherwise I wouldn't be a Rails developer), but I like a little more fluidity on the front end, especially when it comes to tweaking layouts for the small screen.
On the other hand, there are instances where I think Bootstrap is a good idea and that the trade-offs are worth it.
- Very large, very complicated web apps or sites. - Bootstrap offers a lot of consistency and constraints and common practices which can offer some much needed standardization structure to very large, very complex front-ends.
- Collaborative projects among several front-end developers, or projects being handed over to a different dev team. - Similarly, that consistency and standardization of the approach taken to front-end development can ease a lot of pain points when working on teams, because it gets and keeps everyone on the same page.
- Rapid prototyping and internal tools. - for something that needs to be highly customized, Bootstrap isn't necessarily faster, but for something like an app that needs rapidly prototyped, or internal tools where issues like brand awareness and image aren't a concern, Bootstrap can save time and effort. Even if it doesn't save time in development, Bootstrap essentially allows you to skip large chunks of the design process if you want to and still end up with an app that has a highly usable and non-hideous interface.
So now let's move on and answer some questions!
If I'm not a fan of Bootstrap, why did I decide to use it anyway?
For this particular side project, I chose Bootstrap for a couple of reasons.
- We needed rapid prototyping to get an MVC version of the software out quickly. Bootstrap gave us a lot out of the box to work with for that purpose.
- I'm building the app for a non-developer friend and this may not be code that I maintain long-term. Since my friend isn't dev-savvy, I wanted to minimize the difficulties he may face when onboarding other developers to the project.
If Bootstrap isn't my go-to, then what do I use?
If I don't use a CSS framework, don't I often find myself needing to duplicate the functionality that one would provide?
Not as much as you might think. There will always be layouts with columns and images and fonts that need to scale, but by and large, I don't follow any strict rules about when and where in a layout those things should happen, so the need to roll my own "CSS grid system" (which seems to be the part that most people think of when they think about CSS frameworks) doesn't come up very often in the strict, building a reusable grid sense.
I tend to follow a very simple philosophy when it comes to responsive sites, to quote Jon:
Start with the smallest screen size. Resize the window until something starts to look like crap. Add a breakpoint. Repeat.
It's not rocket surgery, and it's perhaps not "structured" enough for some people's liking, but it guarantees a layout that will look good across a wide variety of screen sizes and it gives you far more granular control over your layout then using a grid system does.
It won't work for every project, but it works for most projects, and it's easy and fast.