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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Here’s what happened in roughly the same twelve months.<\/p>\n
Bootstrap shipped 5.3.8<\/a> 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.<\/p>\n Tailwind shipped v4.1, v4.2, and v4.3<\/a> in that window. The v4.3 post from May is a good snapshot of the pace: scrollbar utilities, a 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, Bootstrap gives you working JavaScript components. That’s the whole pitch and it still holds up. A modal is this:<\/p>\n 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.<\/p>\n For the admin panel I mentioned, that mattered more than build times. I quoted Bootstrap.<\/p>\n 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.<\/p>\n Old way, Tailwind 3:<\/p>\n 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.<\/p>\n New way:<\/p>\n Now Bootstrap gets partway there. Since 5.3 it exposes CSS custom properties and Which works, and which also means every theme change is a build.<\/p>\n This one comes up in every thread and it’s less interesting than people think.<\/p>\n Tailwind’s pitch since v4.0<\/a> is that you ship only the utilities you use, detected automatically, no 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n I said the shipping cadence pushed me toward Tailwind. It’s fair to say what it costs, because I’ve paid it.<\/p>\n Buried in the v4.2 notes: 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.<\/p>\n 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.<\/p>\n I stopped asking “which framework is better” and started asking two questions.<\/p>\n 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<\/a> are better than most paid products.<\/p>\n 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.<\/p>\n@container-size<\/code> variant for block-axis container queries, zoom-*<\/code>, tab-*<\/code>, stacked and compound @variant<\/code> support in CSS.<\/p>\ncolor-mix()<\/code>, @property<\/code>, 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.<\/p>\nWhat Bootstrap still does better, and I mean it<\/h2>\n
<button data-bs-toggle="modal" data-bs-target="#confirm">Delete<\/button>\n\n<div class="modal fade" id="confirm" tabindex="-1">\n <div class="modal-dialog">\n <div class="modal-content">\n <div class="modal-header">\n <h5 class="modal-title">Are you sure?<\/h5>\n <button class="btn-close" data-bs-dismiss="modal"><\/button>\n <\/div>\n <div class="modal-body">This can't be undone.<\/div>\n <\/div>\n <\/div>\n<\/div>\n<\/code><\/pre>\nWhere the CSS-first config actually pays off<\/h2>\n
\/\/ tailwind.config.js\nmodule.exports = {\n theme: {\n extend: {\n colors: {\n brand: { 500: '#4f46e5', 600: '#4338ca' },\n },\n },\n },\n}\n<\/code><\/pre>\n@import "tailwindcss";\n\n@theme {\n --color-brand-500: #4f46e5;\n --color-brand-600: #4338ca;\n}\n<\/code><\/pre>\nbg-brand-500<\/code> works and so does color: var(--color-brand-500)<\/code> in a stylesheet Tailwind never touched. Same token, one definition. I wrote more about that migration in the CSS-first config I actually ship<\/a>.<\/p>\ndata-bs-theme<\/code> 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:<\/p>\n$primary: #4f46e5;\n@import "bootstrap\/scss\/bootstrap";\n<\/code><\/pre>\nThe bundle size argument is mostly over<\/h2>\n
content<\/code> 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:<\/p>\n\/\/ Only what you need\n@import "bootstrap\/scss\/functions";\n@import "bootstrap\/scss\/variables";\n@import "bootstrap\/scss\/mixins";\n@import "bootstrap\/scss\/grid";\n@import "bootstrap\/scss\/buttons";\n@import "bootstrap\/scss\/modal";\n<\/code><\/pre>\nTailwind’s pace has a bill attached<\/h2>\n
start-*<\/code> and end-*<\/code> are deprecated in favour of inset-s-*<\/code> and inset-e-*<\/code>. Sensible rename, lines up with the new inset-bs-*<\/code> and inset-be-*<\/code> 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.<\/p>\nHow I actually decide now<\/h2>\n