Best Practices and When Not to Use Bootstrap — Bootstrap Tutorial

You now know enough Bootstrap to build a full page — grid, typography, components, forms, JavaScript widgets, and basic theming. This closing lesson covers the habits that separate a maintainable Bootstrap codebase from one that turns into class-name soup, and when Bootstrap isn't actually the right tool.

Common mistakes

Overriding with !important instead of the Sass variables. The single biggest sign of a struggling Bootstrap project is a stylesheet full of !important rules chasing Bootstrap's own specificity. If you're fighting the framework this hard, you either need the Sass customization approach from the previous lesson, or you've picked a component that doesn't fit and should build custom markup instead of forcing Bootstrap's.

Nesting containers, or grids inside grids without a container. A .row outside a .container/.container-fluid loses its intended alignment because the container's padding is what the row's negative margin is designed to cancel out. Similarly, nesting a full .container inside another container (rather than just a .row) doubles up padding unexpectedly.

Mixing Bootstrap 4 and Bootstrap 5 syntax. Pasting a Bootstrap 4 snippet (data-toggle, ml-*/mr-* margin classes, .form-group) into a Bootstrap 5 project often looks fine in the browser at first glance but silently breaks JavaScript-driven components, since data-toggle without the bs- prefix does nothing in v5. When copying examples from older tutorials or Stack Overflow answers, check which version they target.

Treating utility classes as a substitute for semantic HTML. <div class="btn" onclick="..."> is still a <div> pretending to be a button — Bootstrap's classes provide appearance, not the keyboard and screen-reader behavior a real <button> gets automatically. The accessibility lesson in this course covers this in more depth, but it bears repeating here: styling never substitutes for correct markup.

Keeping a project maintainable

Centralize theme overrides in your Sass variables file rather than scattering component-specific overrides across multiple stylesheets.
Avoid deeply nesting grid classes more than two or three levels — if a layout needs that much nesting, custom flexbox or CSS Grid, applied directly, is often more readable than a wall of col-md-* classes.
Keep a short internal reference of which breakpoint your team treats as "mobile vs. desktop" (commonly md or lg) so navbars, grids, and display utilities collapse consistently at the same point across the whole site.

When Bootstrap isn't the right choice

Bootstrap's component classes (.card, .btn-primary, .navbar) work well when you want a conventional look quickly and don't need to fight the default design much. Two situations where it's worth considering an alternative:

A highly custom design system. If every screen needs to look meaningfully different from default Bootstrap, you'll spend more time overriding component classes than you'd spend styling from scratch — at that point a utility-first library like Tailwind CSS (which ships almost no pre-styled components, only low-level utility classes like Bootstrap's own d-flex or mt-3, but for every CSS property) can be a better fit, since you compose your own components' look from utilities rather than un-styling someone else's.
Bundle size on a component-light page. A landing page using two or three components doesn't need the CSS for modals, carousels, and toasts it never renders — the Sass "import only what you need" approach from the previous lesson helps, but a utility-first framework with build-time purging can end up leaner still.

Neither approach is strictly better — Bootstrap trades some customization flexibility for speed and a batteries-included set of accessible, tested JavaScript components; a utility-first library trades that head start for finer control and a smaller default footprint. Knowing both means picking based on what a given project actually needs, rather than defaulting to whichever one you learned first.

Common mistakes

Keeping a project maintainable

Centralize theme overrides in your Sass variables file rather than scattering component-specific overrides across multiple stylesheets.

Avoid deeply nesting grid classes more than two or three levels — if a layout needs that much nesting, custom flexbox or CSS Grid, applied directly, is often more readable than a wall of col-md-* classes.

Keep a short internal reference of which breakpoint your team treats as "mobile vs. desktop" (commonly md or lg) so navbars, grids, and display utilities collapse consistently at the same point across the whole site.

When Bootstrap isn't the right choice

A highly custom design system. If every screen needs to look meaningfully different from default Bootstrap, you'll spend more time overriding component classes than you'd spend styling from scratch — at that point a utility-first library like Tailwind CSS (which ships almost no pre-styled components, only low-level utility classes like Bootstrap's own d-flex or mt-3, but for every CSS property) can be a better fit, since you compose your own components' look from utilities rather than un-styling someone else's.

Bundle size on a component-light page. A landing page using two or three components doesn't need the CSS for modals, carousels, and toasts it never renders — the Sass "import only what you need" approach from the previous lesson helps, but a utility-first framework with build-time purging can end up leaner still.