I don’t believe the Tailwind approach is a stable, scalable, or reliable solution for large, long-living products.

It works well for fast delivery, prototypes, and teams optimizing for short-term speed, but over time it tends to spread styling decisions across markup, making the system harder to control, reason about, and maintain.

I agree. But also, on a broader note, I have no desire to introduce node for the sole purpose of some css niceties.

Coming back a couple of years later to a broken build system when you just want to change a colour is no fun.

"Bootstrap takes the opposite approach by limiting flexibility and embedding decisions into predefined components."

If you choose tailwind, nothing is stopping you from using components. You can choose to use predefined components, or you can create your own. Or some mix.

My thoughts too. There's no real reason I can think of that you couldn't build a Bootstrap on top of Tailwind. They're kind of at different levels of the stack.

Things like Shadcn are effectively Bootstrap on top of Tailwind.

I do not think the comparison really holds up.

Tailwind can produce wildly different and highly customized results; Bootstrap generally cannot. They are different approaches, and preferences are obviously valid, but I do not think they are really comparable in that sense.

Personally, I think vanilla CSS is great, but Tailwind offers a similar level of versatility while also making the way styles are written more uniform, which matters when you are working in a team and do not want everyone reinventing the wheel.

And with components, I do not think the repetition is nearly as bad as people claim.

Ah, time for the pendulum to start swinging back again

What happens in practice is you use Tailwind with components (React or otherwise), so you build `<Button primary>` using tailwind classes internally; this is functionally the same as the boostrap classes, but can standardize much more than styles.

It just adds an extra layer of abstraction, which I happen to also find unnecessary.

> It just adds an extra layer of abstraction, which I happen to also find unnecessary.

Can't tell if you're talking about React or Tailwind

DaisyUI[0] is the Bootstrap on Tailwind.

Bootstrap makes everything looks the same. With Tailwind, most of the times and besides the colors, you have to look in the code to know it's Tailwind.

[0]https://daisyui.com/

i just write svelte components with normal css. no complex hierarchy, no long class names, no forced structure, no runtime cost, global rules are opt in. everything exactly the way i want without hacks and boilerplate.

I do exactly the same.

> everything exactly the way i want

Can relate.

I am missing the point of Tailwind?

Don't you get the same effect and functionality from simply adding style attributes directly on the elements in HTML?

Why is that approach considered bad practice, while Tailwind, which is effectively the same – but with shortened names – accepted as common practice?

As the article states, at least with Bootstrap you are sharing common behaviour with a single class name that can then be modified globally.

My point is when you have 100 different ways to achieve result - it's always led to inconsistency. And it's very dangerous in large distributed app because resolution of those small differences means you have to support 50+ variation of the same submit button.

Personally I'd prefer to have up to 5-10 option of buttons for all possible cases. And it's not only visual simlicity, and not only easier to support but even help your own customers because they are not have to looking for 100+ different button styles.

Tell 'em! I also hate React and love Razor, but most don't seem to share that sentiment

Just use DaisyUI

Indeed. Claude jammed DaisyUI into a vibe code weekend project when I wasn't looking, and I've actually been pretty happy with it even now that I have to code myself (AI starts to really suck ass for the last 20%, so I usually take over then, but love the bootstrapping and PoC-ness). Petal UI is usually my preference, though that's only on Elixir LiveView (but that's my stack of choice anyway)