≡ Menu

Bootstrap considered harmful

Published on by Hidde de Vries in thoughts

Bootstrap has become a very popular tool in front-end projects over the years, and it can have huge benefits. However, if your team has a front-end developer on board, I would argue you may be better off without Bootstrap. In some instances, it can do more harm than good.

What Bootstrap is great for

Bootstrap comes with a grid, but also with styles and scripts for many components, including tables, navigation bars, progress bars, paginations, form styling, modals and tooltips. In this article, by ‘Bootstrap’, I mean the practice to include all of it (as opposed to choosing to include part(s) only, i.e. just its grid).

Bootstrap is a great tool for back-end developers who need markup to output their program into, and don’t want to worry about styling the result. If for some reason, budget or otherwise, there are no front-end developers or designers in a team, Bootstrap is great to fill that gap.

For designers, Bootstrap has its place too: it can be a valuable tool to move quickly from design software into the browser, without worrying too much about front-end coding strategies.

Even for front-end developers that mostly work with data and less with UI and layout, Bootstrap can be fantastic at letting a developer focus on building the application itself.

When you’re better off without it

However, if you have a front-end developer on your team, using Bootstrap could potentially waste their dear time, and shift their focus away from solving real problems. Bootstrap does the very thing front-end developers have expertise in, but it does them in a very generalised way. Asking front-end developers to use Bootstrap is like asking carpenters to assemble IKEA furniture.

Your website or web app is very specific, so if you use a generalised system it is likely not going to fit. This means that your code will contain a whole lot of exceptions, to make all the specific possible.

When lots of exceptions are required to unset Bootstrap’s styles

Bootstrap was once made by developers at Twitter to systemise the style of their web app. When your web app is not styled like theirs, this means you will have to unset what they do.

Most websites are not styled like Twitter. Therefore, if they load Bootstrap, they will need to unset a lot.

In some websites I worked on, I saw as many as 9 out of 10 Bootstrap styles being unset by the site’s own styles. To put it quite frankly, that’s ridiculous.

When it makes simple things complex

CSS is made to add simple sets of style rules to web pages, which can be conditionally overridden. When Bootstrap’s CSS is in your site, almost all the things are already set using a complex set of style rules. Any exceptions go on top of that. The issue with most sites is that most of their styles will be exceptions to Bootstrap styles.

Bootstrap’s styles are complex: you can have a grid that has 12 columns which can be used in any combination you want, with special classes taking care of skipping columns and setting column structures differently based on the user’s viewport. Many websites are simple: they only have no columns on small screens and one or two on larger screens.

When it creates technical debt

The longer a front-end code base relies on Bootstrap, the more it gets entangled with it, and the more rules it contains that exist just to unset Bootstrap stuff. This, more often than not, leaves the codebase in huge technical debt, especially if front-end code is implemented in the back-end in a way that requires manual updating (which is often the case). Removing Bootstrap will be harder over time, as too much relies on it.

When it introduces naming conventions that may not be your app’s

Naming things is hard, and it takes time to come up with sensible naming conventions that work for your team and app. Using proper nouns for component names doesn’t mix well with classnames like ‘btn’ that are abbreviations of proper nouns.


Bootstrap and friends can be beneficial for all kinds of stages in the process of making websites. They are however not a magic bullet that will make everything easier: on the contrary, there are many downsides that can be avoided by having a front-end developer focus on coding the UI by hand.

Comments & mentions (14)

AJ 10 Aug 2016 22:44:03

These are really good observations. Great piece!

kem 11 Aug 2016 11:50:54

So… the title should be “think about when and how it’s appropriate to use Bootstrap” rather than “Bootstrap is considered harmful”, right?

Frankie Loscavio 12 Aug 2016 00:27:54

The title of this article is misleading and incorrect. I too agree that it should be:

“think about when and how it’s appropriate to use Bootstrap” rather than “Bootstrap is considered harmful”

The previous comment is spot on.

Teddy Cross 12 Aug 2016 02:44:30

This piece completely misses the best use case of Bootstrap: via LESS or SASS, allowing full control over the style of the entire framework.

Hidde 12 Aug 2016 05:45:15

@kem/Frankie: thanks for your comments! Fwiw, earlier drafts of the article had titles not too dissimilar from your suggestions.

@Teddy: I’m aware the framework is customisable from preprocessors like Sass and LESS. That is helpful and can mitigate some of the damage Bootstrap can do, but in my experience it can still leave one spending more time unsetting than it would cost to write something yourself (again, if your site/app looks nothing like Twitter/Bootstrap that is). Also, I have seen various teams that did go for the modular approach, and then did not take the time to pick only the bits they needed.

Vincent 13 Aug 2016 11:20:52

Nice piece. But I agree with Teddy on this, I personally tend to only include the grid system from Bootstrap via SASS and that’s all. Nothing to unset :)

Mundiff 14 Aug 2016 11:49:38

While I do agree that bootstrap is bloated, like other commenters have mentioned, you can pick and choose what you include and set styles globally using less etc.

I get it all the time from our art director that our website looks too bootstrappy. But other than the navbar there’s nothing that looks inherently different than any other website.

The one issue i have, and it’s probably the case with other frameworks, is that every major release they change some class names. Like bootstrap 4 will get rid of img-responsive for images. I’ve been using that for years so it will make it slightly more difficult to upgrade. Other than that it’s a nice starting point for a lot of projects and generally follows best practices. I learned a lot from using it and following it’s progression.

Hidde 14 Aug 2016 12:09:05

Note that in the last sentence of the first paragraph after the intro I explicitly say I am against including ‘all of it’, not against picking and choosing bits of it.

@Mundiff: interesting addition, I had not thought of that, and think it’s another disadvantage of frameworks like Bootstrap.

The opportunity to learn about good practices which you mention is absolutely an advantage that these frameworks bring. But I would still suggest learning from them outside your production code (it sounds like that’s what you do when using pick and choose, great!)

John Polacek 14 Aug 2016 13:09:09

Three years ago I wrote The Bootstrap Trap and many people were upset that I would question their beloved front end framework (see the comments). http://johnpolacek.com/2013/08/26/the-bootstrap-trap/

Note: I am glad Bootstrap exists. It is a nice barometer of the current thinking in front end web dev. I am also glad to see that more and more people are coming around to agree with me :)

Steven Grant 14 Aug 2016 20:58:25

@Teddy even using Bootstrap via LESS or Sass is more time consuming than writing your own styles. There’s always a rogue variable that doesn’t quite overwrite properly. Generally I use the ‘good’ parts of Bootstrap, grid framework, helper classes, form styles; the really generic stuff.

Kristian Serrano 23 Aug 2016 20:33:02

I’ve moved to Bourbon + Neat + Bitters (http://bourbon.io). A much more sustainable approach and relatively future proof.

Victor Longon 25 Aug 2016 06:07:05

I couldnt agree more. Every time a have used it wad because I inherited a project that already had it.

Martin di martino-Marriott 25 Aug 2016 13:14:35

Are we still on this? We all know to wield our tools responsibly with the interests of the team and our particular app in mind. We know that we should resist the short-term gain promised by Bootstrap et al. because we know it creates us headaches later etc. It’s a well-trodden debate.
In our team we’ve done as @Kristian has done and opted for the lighter Neat and Bourbon products; not looking back. M

Jay Wolters 01 Sep 2016 22:43:10

The statement “Many websites are simple: they only have no columns on small screens and one or two on larger screens.” is short-sighted given the nature of grid based layouts. Having a side bar next to the main content area should not be seen as a simple two column layout. Claiming that Bootstrap is “complex” for providing a 12 column grid is incorrectly dismissive. Susy, Neat+Bourbon (et al) provide mechanisms to ensure vertical rhythm in the form of a grid and many people have already stated that this grid might be the only good part of the framework worth having.

Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.