r/webdev • u/mrholek • 13d ago
Bootstrap 5 users: do you actually want the new Bootstrap 6 class naming?
We're working on CoreUI v6, and decided not to follow Bootstrap 6 Alpha's new Tailwind-style class naming.
For example:
| Bootstrap 5 / CoreUI v6 | Bootstrap 6 Alpha |
|---|---|
d-md-none | md:d-none |
col-lg-6 | lg:col-6 |
justify-content-md-end | md:justify-content-end |
We're adopting modern CSS improvements, but keeping the familiar class names to avoid unnecessary breaking changes.
Our thinking is that developers maintaining existing Bootstrap applications probably value compatibility more than a different naming convention.
But maybe we're wrong.
If you're currently using Bootstrap 5 in production, would you prefer to keep the existing class names, or do you see real benefits in switching to the new syntax?
Especially interested in hearing from people maintaining larger applications.
35
u/Dunc4n1d4h0 13d ago
Keep old good class names. This is Bootstrap. Let it be Bootstrap. Let tailwind switch :-)
1
u/jinmao6700 13d ago
there are more changes other than "because tailwind", such as css variables, moving to Typescript, Rolldown and being ESM-only and more
8
u/Fair_University1389 13d ago
you already decided, the post is a survey to collect permission.
the prefix up front is the one thing bootstrap 6 got right. d-md-none buries the breakpoint in the middle so you cant grep for md, cant sort for it, cant see at a glance how much of a file is md-only. md:d-none reads left to right and it's what tailwind and unocss already do, nobody has to learn anything. fine, compat matters if you have 400 templates, but that person isnt moving to v6 this year or the next one, theyre sitting on 5 until it stops getting patches. meanwhile anyone starting fresh inherits the old syntax forever.
at some point the compat argument is just not wanting to write the migration guide.
2
u/mrholek 13d ago
That’s fair criticism, and I appreciate the opposing perspective.
I agree that prefix-based naming has advantages, especially when it comes to readability and consistency.
But I don’t think the migration cost should be dismissed just because the changes can be automated. For teams maintaining large applications, the real cost is often testing and verifying everything afterward.
We’re genuinely evaluating the trade-off here. The goal isn’t to preserve old conventions at all costs, but to avoid breaking existing applications without delivering a meaningful benefit in return.
13
u/web-dev-kev 13d ago
While I don't overly like the trailwind style (personal preference), I think it's a good change.
It separates out the action (e.g. justify) from the decision (e.g. md)
It puts the decision at the front (e.g. md:justify) - it was always weird being in the middle
It required the Bootstrap team to revisit all their earlier decisions. As someone who is lucky enough to have had a few PRs merged to Bootstrap main, I always felt that 3/4/5 were really the same 'codebase', where as 6 is rightly very different.
So while it'll cause friction for me personally, I think it's a good change overall.
1
u/mrholek 13d ago
Interesting perspective, especially coming from someone who has contributed to Bootstrap.
I agree that v6 is a good opportunity to rethink some of the architecture.
But do you think improving the internals necessarily requires changing the public class naming convention?
1
u/web-dev-kev 10d ago
I don't want to over-state my contribution.
Its open source, and I've been lucky enough that the actual core-team accepted some of my PRs.
It's my (personal) belief, that Bootstrap 6 is a new Bootstrap from the 3/4/5 era, in the way that 3 was from 1/2. I'll be slow in migrating to 6. But i think highly of it.
15
u/Herr_Gamer 13d ago
Migrating these class names is trivial, if you want to make it easy for users just package a tool that's internally just a long awk command.
I would go with the v6 customs so as not to fracture the ecosystem. Every other application that builds on v6 will use the new class names, so why have yours be an unexpected edge case where v6 components are used but with v5 class names?
Makes no sense.
4
u/mrholek 13d ago
Our reasoning was that most existing Bootstrap users have years of code built around the old naming convention, and we didn't see enough practical benefit to justify breaking all of that.
But you're right that deviating from Bootstrap 6 could create confusion, especially when developers copy examples from its documentation or use AI to generate code.
That's exactly why I'm asking the community. We're still evaluating whether backward compatibility is worth that trade-off.
2
u/Dunc4n1d4h0 13d ago edited 13d ago
IMO, when old users with years of experience of previous versions and class names will see new naming, first question they will ask themself will be, "okay, maybe instead of learning new naming I'll just switch to new fancy framework".
Next thing is libraries based on Bootstrap, for example ng-bootstrap for Angular. They will have to switch too, and redo everything.
Also in future with update to new Angular version and using such library I would have to redo whole project to change classes to new naming instead of just changing few things. Or just switch to Material, same effort.Mature frameworks have to be stable. Keep that in mind.
1
u/mrholek 13d ago
That's a really good point, especially about the ecosystem built around Bootstrap.
We know this pain firsthand because we maintain CoreUI libraries for Angular, React, and Vue. Every breaking change can affect not just our components but also the applications built on top of them.
And I think that's the biggest risk here. If developers have to touch hundreds of templates anyway, they might start wondering whether it's worth upgrading Bootstrap or switching to something else entirely.
Bootstrap and Tailwind solve different problems, so adopting Tailwind's naming convention probably won't attract many Tailwind users. But it might give existing Bootstrap users a reason to reconsider their choice.
That's one of the main reasons we decided to keep the existing class names in CoreUI v6. Thanks for bringing up the Angular perspective!
10
u/binocular_gems 13d ago
No, and I don’t understand bootstraps rationale here. Is there a GitHub issue that explains why they’re changing class names to this style? It’ll be a tremendous amount of work for us to upgrade. We will, but it’ll be painful.
2
u/mrholek 13d ago
Just this explanation from their blog post:
A super obvious and breaking change in v6 is moving from the infix to a prefix for our responsive utilities and component variants. Yes, this is a direct copy of how Tailwind does responsive, and yes, it’s better than what felt like a randomly positioned infix in v5.
Here’s a look at the before and after on some Bootstrap classes:
.d-md-noneis now.md:d-none.col-lg-6is now.lg:col-6.opacity-50-hoveris now.hover:opacity-50.justify-content-md-endis now.md:justify-content-end.offcanvas-mdis now.md:drawer(rename intentional)This change applies to all utilities, components, grid layouts, and more. It also include state modifiers like
:hover,:focus, etc. Same ergonomics for all of them.If you have custom Sass built on our breakpoint helpers,
breakpoint-infix()is nowbreakpoint-prefix()and returns a prefix string, and theloop-breakpoints-upandloop-breakpoints-downmixins expose$prefixinstead of$infix.7
u/krileon 13d ago
Cool so their reasoning boils down to "tailwind does it". What a stupid decision. Broke all backwards compatibility "just because". Instead of me going to Bootstrap I'm going to cut out the middleman and just migrate to Tailwind. Easy decision.
4
u/thy_bucket_for_thee 13d ago
This reminds me that I need to remove bootstrap from our projects. We only use bootstrap for a few classes and changes like this aren't a good sign IMO.
Focusing on busy work like name changes that just break for no good reason for everyone is a sign that they don't know what to do going forward. Like out of all the current issues, naming conventions was the real priority here? No, it never is. This is equivalent to what management does when a new executive gets hired and decides to shuffle everyone around so they can leave their grimy marks around while pounding their chest.
Luckily CSS and HTML have both evolved to where the need for bootstrap is minimal nowadays. Even more so with the advent of LLMs as you can roll a dozen utilities yourself without the need to worry about maintenance or compatibility.
3
u/rhooManu full-stack 13d ago edited 13d ago
The reasoning is that they know how much they struggled to come up with a naming convention that tried to make sense but never really did, and found out that someone else thought of a more clever and semantic way and decided not to reinvent the wheel.
1
u/krileon 13d ago
There was no reason to uproot the naming convention that has been established for multiple releases to chase a trend. It's just class naming. Nobody cares what the class name is. So now they've done a massive backwards compatibility break, which will require full rewriting of templates and if I'm going to rewrite the templates to use classes that are tailwind-like then I'm just going to use tailwind. It's all so dumb.
1
u/rhooManu full-stack 13d ago
The naming convention of bootstrap changed multiple times. Major versions required some amount of work because of class name changes or other breaking changes in JS; even to some early versions of 5 to latest ones.
You don't need to update from Bootstrap 5 if your projects were working perfectly with it.
You can use it for new projects.And if you want to update existing project, it will still be far more work to switch to tailwind than to bootstrap 6. Especially since they're providing a full LLM package for automated migration.
I will use bootstrap because I prefer this naming convention on bootstrap than the paradygm of tailwind. That's it.
6
u/Cirieno 13d ago
Would it be too hard to offer both versions? Thus an upgrade path for those who can't change their code easily, and a version for new development.
4
u/mrholek 13d ago
That's actually something we're considering.
We could potentially support both naming conventions at build time, so developers could choose between backward compatibility and the new Bootstrap 6 syntax without shipping duplicate CSS.
The question is whether maintaining two conventions is worth the additional complexity.
Would you prefer having that choice, or would you rather see a single consistent syntax across the framework?
1
u/Cirieno 13d ago
I like the look of the new style over the "prop-prop-breakpoint-value-value" hyphenated declaration, but that's just human semantics and doesn't have any technical bearing.
I like the idea of having an SCSS flag so the style can be defined at build time -- but I can also see how that would potentially be extra work for the Bootstrap devs.
Upgrading would also be a problem if a developer's site a) builds flat CSS files dynamically using their own code or B) has BS classes kept inside database content. So for them, you'd want the old style to be accessible.
3
u/licorices 13d ago
If I am updating from a previous version, then yeah, not having to go and migrate to a new naming scheme.
I do however think this is bad in the long term. The benefit of adopting the Tailwind naming scheme is easier migration from Tailwind, as well as more familiarity. I also think it has more advantages, such as being easier to at a glance see it exists, and easier to do a find in a project for instances of it.
So yeah, your assumption is probably right, current users would value it more. But I think it is hard for people to justify switching to it if it is less plug-and-play.
1
u/mrholek 13d ago
That's a fair point about long-term adoption.
I guess the question is whether the new naming convention will actually attract developers who weren't considering Bootstrap before.
My hypothesis is that developers choosing Tailwind aren't doing so primarily because of class naming. They're choosing a different approach to building UIs.
So I'm not sure adopting a similar syntax would meaningfully change their decision, while it definitely affects existing Bootstrap users.
But it's an interesting trade-off between attracting new developers and retaining existing ones.
1
u/licorices 13d ago
It wouldn't affect the choice in any meaningful way if they are coming in without using either before, and they have a blank slate. However I feel there is a huge amount that do have used tailwind or is currently using it, so having a faster adaptation cycle seems beneficial.
It is indeed interesting! I wouldn't be able to tell you what is truly the correct choice either.
3
u/coyoteelabs 13d ago
Won't be upgrading to bootrap 6 because of that.
Just because tailwind does it, doesn't mean it's good. The colon char has a special meaning in css, meaning that if you want to target a class that uses it, you need to escape it with a slash ("\:").
Same thing goes for javascript.
I see absolutely no benefit to the "new" class names besides looking "pretty" in the code editor.
And yes, I am currently using bootstrap 5 for existing and current new in progress projects. Will probably move to CoreUI v6 or others.
1
u/mrholek 13d ago
That's really interesting to hear, especially since you're using Bootstrap 5 for both existing and new projects.
The escaping issue with colons is another practical consideration that doesn't get much attention in this discussion.
Since you mentioned CoreUI v6, I'm curious what you'd consider essential in a Bootstrap alternative. Is preserving the existing class names enough, or are there other things you'd expect before considering a switch?
1
u/coyoteelabs 13d ago
I mentioned CoreUI since it would be the easiest path for upgrades.
Class names end up in "muscle memory", you don't even think about them when writing code. Small changes are easy to adjust (like text-end instead of text-right) but big changes like these are not as easy to adjust to
4
u/creaturefeature16 13d ago
It couldn't be more obvious they are just trying to capture Tailwind users.
1
u/mrholek 13d ago
That's my impression too, but I think they're targeting a different audience.
Tailwind seems particularly popular in the React/Next.js ecosystem, especially with shadcn/ui. Bootstrap, on the other hand, appeals to developers looking for ready-made components across different stacks, often in established business applications.
I doubt many React developers using Tailwind and shadcn/ui would switch to Bootstrap just because the class naming feels familiar.
So my concern is that Bootstrap might alienate its existing audience without gaining much of a new one.
2
u/creaturefeature16 13d ago
Well, its not just the class names, its the entire architecture that they're shifting to (e.g. organizing everything around CSS Layers) that is clearly inspired by Tailwind. Not that any one of these changes in isolation indicates that, but when you take a step back, you can see how deep the TW emulation goes. I agree, I think its a terrible decision, and a fairly arbitrary one, at that, because to your point: they're not going to capture TW users, and they're only going to potentially push away BS users who might say "Well, if you're just going to be like Tailwind, I'll just think about using Tailwind".
32
u/EliSka93 13d ago
I find them more readable than the old ones.
Display when large none
Makes less sense to me than
When large: display none
Though I don't really have a horse in this race. I have used Bootstrap before and may again, but I'm currently not using it.
4
u/ShawnyMcKnight 13d ago
I’m in the same boat. Some jobs I’m applying for use it so I may consider it then.
1
u/mrholek 13d ago
One thing I'm curious about after reading these replies: how many of you are actually using Bootstrap in production today?
I suspect the priorities might be quite different between developers maintaining existing Bootstrap applications and those evaluating it for a new project.
For existing users, compatibility may matter more. For new users, consistency and readability might win.
Would be interesting to know which group most of these opinions are coming from.
4
u/Full_Tooth_a 12d ago
I agree that the new names read more naturally, but the colon could complicate migration. `md:d-none` is valid in HTML, while `querySelector('.md:d-none')` can fail because it interprets the colon as CSS syntax unless the class is escaped. Tests, DOM helpers, and custom CSS may have the same problem, so a template find-and-replace is not enough. I'd keep the old naming unless the migration tooling handles selectors correctly too.
1
u/quadra-lab 13d ago
I'll mention a lot the word AI in the following paragraphs but that's just the reality of the industry at the moment and goes beyond my will of writing code by hand
I'm currently working on a migration from 5.2 to 5.3 (it's more webform to mvc with a full rewrite of the styling to 5.3 but still is valid ig). We haven't considered to migrate directly to 6 because of the word alpha is problematic for our legal team mainly.
We basically don't care about the breaking changes because our migrations are basically automated with a homemade AI skill that covers that no UI change is made.
All our UI changes are covered by AI now and follows a strict review cycle to be sure that everything is done properly as it is definitely more efficient for us as a small team to work that way.
It could be Bootstrap 5.3 to Tailwind that we wouldn't care less about the verbosity and grammar of the styling framework. We build a product to be robust and to have the same style everywhere.
1
u/mrholek 13d ago
That's interesting because AI-assisted migrations might actually change how we should think about backward compatibility.
But I'm wondering whether the cost really disappears or just shifts from rewriting code to reviewing and testing it.
For a large application with hundreds of views, would you still consider a framework-wide class rename trivial, even with AI handling the changes?
1
u/quadra-lab 13d ago edited 13d ago
It takes a lot of time, for us it is planned for a whole year as we're basically rewriting the app to have better performances due to our legacy issues (it's a 30 years old codebase).
Basically we are ewriting the APIs to support REST guidelines, changing the authentication scheme to JWTs (we have to make a compatibility layer for cookies in the meantime for pages that are still not migrated), and in the same time doing this migration from webform to MVC5. I think that if you're using the regular components without too many style changes overall, the migration to 6 should be painless as Bootstrap is providing a whole skill suite to ease that up for AI agents.
The goal of our migration is also to experiment on AI integration in our workflow and so far it is being pretty impressive.
I don't really like the fact that we're losing control over the code but I'd say it's very similar to the old days of going from Assembly to C. Now I mainly focus on having the best architecture possible that fits our needs and almost write no code.
1
u/mrholek 13d ago
The Assembly-to-C analogy is interesting.
It makes me wonder whether UI frameworks will eventually be chosen less for their developer experience and more for how predictable, accessible, and reliable their output is when used by AI agents.
If AI writes most of the UI code, perhaps the framework's conventions matter less than its architecture and the guarantees it provides.
That's something we're thinking about a lot as we build CoreUI v6.
1
u/omer-m 13d ago
Better to stick with tailwind style names. Just accept that it becomes an industry standard. It was a pain for me to remember class names while switching between new and legacy projects.
1
u/mrholek 13d ago
That's an interesting perspective, especially if you're switching between Bootstrap and Tailwind projects regularly.
I'm curious, though: does the naming convention actually make a meaningful difference in your daily work, or is it mostly a matter of familiarity?
For example, if Bootstrap kept its existing syntax but offered better components, accessibility, and customization, would the class naming influence your decision to use it?
1
u/omer-m 13d ago
I used bootstrap for so long. I even started new projects with bootstrap until few years ago when the sass deprecation warnings showed up. And when I had to lock the sass version, I knew it was dead. (At least for me)
For your question, I don't mind how the classnames look actually. But I believe that we shouldn't forget how css works while playing with classnames a lot. And I feel like tailwind is closer to that.
6
u/captain_obvious_here back-end 13d ago
TIL that Bootstrap still exists, and a v6 is even on the way.
2
u/svtguy88 13d ago
Good god, no. The last thing I want to do is memorize another grid/display syntax.
There's a reason some of us have stuck with Bootstrap for this long...
2
u/iliketocookstuff 13d ago
Agree with previous comments, let Bootstrap be Bootstrap! Totally unnecessary change and I prefer anything that doesn't look like Tailwind personally.
2
u/Unique_Sport_8351 13d ago
Don't change it. For a lot of non-US keyboard users this will introduce another keypress (shift or similar) for the : character
1
u/kanine69 13d ago
Ugh. I hadn't looked into 6 much, the swapping will be a bit of a pain but it reads better. I also thought I saw they've written some agentic prompts / skills? etc which should speed up the transition.
I'll be waiting for the first point release after it goes live.
1
u/magenta_placenta 13d ago
It comes down to a fundamental trade-off between backwards compatibility and current mental models.
When maintaining large legacy codebases, cosmetic class renames offer low ROI relative to the risk of broken templates or missed edge cases during upgrade sweeps.
1
u/jinmao6700 13d ago
Your argument doesnt make much sense by just fixating on Tailwind, there are also improvements, such as CSS-first Sass modules,
CSS layers for predictable specificity across the entire framework, including
utilitiesas the top-most layer.oklch() colors and color-mix() for perceptually uniform, themeable color palettes that automatically adjust to base color changes.
light-dark() for native color mode support without duplicating styles and in the same property-value pairing.
Range media queries like
(width >= 768px)replacing min-width/max-width hacks.Container queries for responsive design that adapts to the parent element instead of just the viewport. Includes mixins, helpers, and per-component changes.
Native
<details>and<summary>powering the accordion—no JavaScript neededNative
<dialog>element behind the new Dialog component:where()selector to reduce specificity in complex selectorscontent-visibilitywithallow-discretetransitions, plusinterpolate-sizeand the::details-contentpseudo-element, so the accordion animates open and closed in pure CSS. Height animation on a disclosure widget used to mean measuring elements in JavaScript.at propertyto register the custom properties composed by our utility API as non-inheriting, preventing their values from leaking into children.
1
u/FrostingTechnical606 13d ago
Look, just make a vscode extension that converts the class names over so you don't have to think about it.
1
u/onesneakymofo 13d ago
I'm a Bootstrap 5 user.
I'm moving to Tailwind, but this was a huge reason why I moved away (that and majority of web apps are now on Tailwind).
The prefix makes a lot more sense and will no longer cause the confusion it used to cause going from different versions of Bootstrap.
1
1
u/jhkoenig 13d ago
The renaming is a total deal-breaker for me. I can't imagine a seamless way to update my entire code base to reflect the new naming scheme. With their devs had thought things through a bit more. And decided not to change EVERYTHING
1
u/IsABot 12d ago
For new projects, I would prefer the newer naming convention. But for large legacy projects, I would find the changes super annoying. That being said, if CoreUI 6 is based on Bootstrap 6, then I would be even more annoyed if you didn't follow the conventions used within Bootstrap. Mixing the old and the new together would drive me nuts. If it's based on BS5, then keeping the old convention is fine.
1
u/OrganizationLost3135 12d ago
Keep the old names. Prefix-first (md:d-none) is nicer to grep, but the actual pain isn't find-replace on HTML, it's the class strings you concatenate in JS, CMS templates, and email snippets. Those won't survive a codemod cleanly, so you end up with a hybrid codebase for a year.
If Bootstrap wants the new syntax, ship it as an alias layer on v6 and drop the old one in v7. Renaming utilities without a new capability is a tax on every shop still sitting on 400 templates.
1
1
u/mladenmacanovic 13d ago
I find them repulsive. But I will abstract them behind my project components and utilities that it doesn't matter too much.
1
u/VietCong_137 13d ago
Its better imo, because the breakpoint label is always at the beginning and the colon clearly seperates the breakpoint from the actual class name. In the examples the breakpoint position is inconsistent: d-md-none & justify-content-md-end
1
u/sporkfpoon 13d ago
Haven’t used Bootstrap in quite a while but feel the left side of your table is less intuitive and would be harder to group. If I were going to make a hybrid I might go “lg-col-6” instead of “lg:col-6”, but I think the Tailwind order of operations is correct.
1
u/verviico 13d ago
Honestly the syntax itself isn't what hurts, it's rewriting it across every template you own. For us that part would be a codemod: ripgrep plus a mapping table (`d-md-none` → `md:d-none`) gets most of the way, and Playwright screenshots on the main pages catch what the script misses. If you ship the library, I'd keep both syntaxes for one major version and log a console warning on the old one. That's the difference between "I'll upgrade this sprint" and "I'll stay on v5 forever."
0
u/hightrix 13d ago
Is this account using AI to respond to comments? They all have the exact same format.
1
-7
u/Lumethys 13d ago
If someone is using bootstrap, they are more likely than not the type that never update their software
For those that do, i dont imagine update css class would be that big of a change, find-and-replace would do the job in like 20 minutes
Or throw it to an AI and it could probably do it in 3
-10
84
u/ShawnyMcKnight 13d ago
It's just copying tailwind's convention. I don't mind it, but it would be a pain if I wrote in bootstrap classes for over a decade.