A client asked me last month whether we should “just use Bootstrap” for an internal admin panel, and I gave the answer I’ve given for about three years: depends on the team, Bootstrap is fine, stop overthinking it. Then I actually went and looked at both projects before writing the estimate, which I had not done in a while.
Bootstrap’s last release was 5.3.8. It shipped in August 2025. It’s still the latest tag on GitHub as I write this, almost a year later.
I want to be careful here, because “framework is dead” posts are lazy and usually wrong. Bootstrap isn’t dead. But I’d been comparing these two on the wrong axis. Every Tailwind vs Bootstrap article argues about utility classes versus prebuilt components, which is a real difference and also a settled one. The thing that actually changed my recommendation was much more boring: I opened both changelogs.
The comparison nobody runs
Here’s what happened in roughly the same twelve months.
Bootstrap shipped 5.3.8 in August 2025. The release notes say, in Mark Otto’s words, “the plan is for this to be the last patch release before v5.4.0 drops.” The contents were a WCAG contrast fix, a cursor fix on search inputs, and a reverted dropdown focus change. Then nothing. No 5.4, no 5.3.9.
Tailwind shipped v4.1, v4.2, and v4.3 in that window. The v4.3 post from May is a good snapshot of the pace: scrollbar utilities, a @container-size variant for block-axis container queries, zoom-*, tab-*, stacked and compound @variant support in CSS.
I don’t think release count is a quality metric. Plenty of stable software should stop changing. But CSS is not stable software right now. Container queries, color-mix(), @property, cascade layers, and logical properties all landed in browsers recently, and a CSS framework that isn’t shipping is a framework that isn’t wrapping any of it.
What Bootstrap still does better, and I mean it
Bootstrap gives you working JavaScript components. That’s the whole pitch and it still holds up. A modal is this:
<button data-bs-toggle="modal" data-bs-target="#confirm">Delete</button>
<div class="modal fade" id="confirm" tabindex="-1">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<h5 class="modal-title">Are you sure?</h5>
<button class="btn-close" data-bs-dismiss="modal"></button>
</div>
<div class="modal-body">This can't be undone.</div>
</div>
</div>
</div>
Focus trapping, escape-to-close, scroll locking, backdrop, ARIA wiring. Free. In Tailwind you write that yourself or you install Headless UI or Radix, and now you have a JavaScript dependency and a component library decision on a project that was supposed to be a form and four tables.
For the admin panel I mentioned, that mattered more than build times. I quoted Bootstrap.
Where the CSS-first config actually pays off
The thing I underrated about Tailwind v4 wasn’t speed. It was that your design tokens stop being a JavaScript object nobody else can read.
Old way, Tailwind 3:
// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: { 500: '#4f46e5', 600: '#4338ca' },
},
},
},
}
That value lives inside a Node build step. Your Storybook wants it, your email templates want it, the one legacy jQuery widget wants it, and each of them gets its own copy that drifts.
New way:
@import "tailwindcss";
@theme {
--color-brand-500: #4f46e5;
--color-brand-600: #4338ca;
}
Now bg-brand-500 works and so does color: var(--color-brand-500) in a stylesheet Tailwind never touched. Same token, one definition. I wrote more about that migration in the CSS-first config I actually ship.
Bootstrap gets partway there. Since 5.3 it exposes CSS custom properties and data-bs-theme for dark mode, so you’re not stuck recompiling Sass to change a color. But the source of truth is still a Sass variable, and overriding it means this:
$primary: #4f46e5;
@import "bootstrap/scss/bootstrap";
Which works, and which also means every theme change is a build.
The bundle size argument is mostly over
This one comes up in every thread and it’s less interesting than people think.
Tailwind’s pitch since v4.0 is that you ship only the utilities you use, detected automatically, no content array to configure. On a small marketing site that’s a few kilobytes of CSS. Bootstrap’s default bundle is around 230KB minified before gzip if you import everything, which nobody should do, and you can get it down a long way with Sass imports:
// Only what you need
@import "bootstrap/scss/functions";
@import "bootstrap/scss/variables";
@import "bootstrap/scss/mixins";
@import "bootstrap/scss/grid";
@import "bootstrap/scss/buttons";
@import "bootstrap/scss/modal";
The catch is that almost nobody does this. I’ve inherited maybe a dozen Bootstrap projects and I think two had trimmed imports. The rest pulled the CDN link and moved on, which is a reasonable trade when you’re shipping in a week.
So the honest version isn’t “Tailwind produces smaller CSS.” It’s that Tailwind’s default is small and Bootstrap’s default is not, and defaults are what actually ship. If your team has the discipline to trim imports, this section doesn’t apply to you and you should ignore it.
Either way, both are dwarfed by whatever JavaScript you’re shipping. I’ve never once diagnosed a slow page and found the CSS was the problem.
Tailwind’s pace has a bill attached
I said the shipping cadence pushed me toward Tailwind. It’s fair to say what it costs, because I’ve paid it.
Buried in the v4.2 notes: start-* and end-* are deprecated in favour of inset-s-* and inset-e-*. Sensible rename, lines up with the new inset-bs-* and inset-be-* utilities. It’s also a find-and-replace across every RTL-aware component you own, and deprecation warnings in your build until you do it.
That’s one example from one minor release. Multiply it by three releases a year. If you have a large component library and a small team, Bootstrap’s silence starts looking less like neglect and more like a feature. Nobody ever got paged because Bootstrap changed a class name.
There’s a second cost people skip. Tailwind’s speed claims are real but they’re about the compiler, not your app. The v4.2 webpack loader took the tailwindcss.com docs build from 932ms to 429ms. Genuinely good. Also: nobody’s users have ever complained about your build time.
How I actually decide now
I stopped asking “which framework is better” and started asking two questions.
First: does this project need interactive components I’d otherwise hand-roll? Modals, dropdowns, tooltips, offcanvas panels, a carousel somebody will insist on. If yes and there’s no React in the stack, Bootstrap is still the shortest path from zero to shipped. Its component docs are better than most paid products.
Second: will this codebase outlive its design? If the answer is yes, tokens matter more than components. You’ll rip out the components anyway. You won’t rip out the color system, and having it in CSS custom properties rather than a Sass map or a JS config makes every future integration cheaper.
Most of my client work lands in the second bucket, which is why I default to Tailwind. Most weekend projects and internal tools land in the first, and I don’t feel bad about that. I’ve shipped both this year; there’s a mix in my recent work.
The honest summary: Bootstrap is a stable library that hasn’t cut a release in a year, and you should know that before you commit a three-year codebase to it. Tailwind moves fast and will occasionally rename something you depend on. Neither is a dealbreaker. They just send you different bills.
Do this in ten minutes
Open your project’s package.json, find whichever of the two you’re on, and check the version against the latest tag. Then open the changelog between your version and current and read the deprecation notes only.
If you’re on Bootstrap and pinned to 5.3.x, you’re fine, and you’ll stay fine for a while. If you’re on Tailwind and haven’t upgraded past 4.1, run the upgrade tool and grep your codebase for start- and end- before the warnings pile up. Either way you’ll know within ten minutes whether the framework you picked two years ago is still the one you’d pick today.
That’s the whole exercise. It’s the one I skipped for three years while confidently telling clients Bootstrap was fine.
