[hashedout]

I see this not as a replacement, but as a novice choice. As noted in the documentation, you can use tailwind classes to customize existing components but if you do not want to you can use it like bootstrap. Even for building a quick prototype which can be made to look good in future is a use case for this.

[hardwaresofton]

I want to note that I was talking about tailwind vs bootstrap and others in the abstract, less so about DaisyUI specifically.

What lead me to make the comment was the discussion point that "btn btn-primary" was so much more useful than 20+ tailwind classes. I agreed (it's something I have come across as well), but

It's clear that Daisy UI will get you up and running quickly and there are lots of similar projects out there that do things like this, but the meta discussion around whether we're going in circles or if we've actually moved forward and found a nice mix between what was the bootstrap style (1-2 classes that do all the work) and tailwind/tachyons (5-10+ classes that do the work).

To make the discussion less meta -- is the future things like DaisyUI? Bootstrap like classes but with the outlet for overriding not being manual CSS but actually being tailwind-style classes? In the past it was Bootstrap + your special large class/baked in styles, but in the future maybe it's "btn btn-primary box-shadow" or whatever, clearly a middle point of sorts

[piaste]

I'm not a frontend developer so I've been watching this from the outside over the years of reading HN.

The impression I got is that Tailwind is essentially CSS 2.0 with warts ironed out (sorry for the unpleasant mixed metaphor):

A) CSS / Tailwind: lots of little 'atomic' classes describing individual visual properties. Easy to understand, easy to customize, but slow to read, slow to get started, with plenty of stuff to learn

B) CSS frameworks / Tailwind components: fewer classes declaratively describing the component's role (eg 'btn-primary'). Quick to get started, elegant to read, but prone to abstraction leakage and trickier to bend to your own exact specifications

There's always been a need for both kind of tools for different projects, in the same way that e.g. network programming may involve anything from bit-banging commands to high-level protocols.

Over the years CSS frameworks kept improving, but CSS was much slower to do so - although it acquired flexbox, grid, etc., the language limitations stayed, and they were bad enough to spawn SASS/LESS out of a genuine need.

Tailwind saw a ton of hype and adoption because all the developers who had always wanted to go the (A) road now had a well-designed set of simple classes they could use with a lot fewer footguns, plus a bunch of developers who had adopted (B) because it was the road that had all the momentum suddenly realized that they probably wanted to use (A) once it was made less painful.

DaisyUI and similar projects don't do anything that Bootstrap didn't do for CSS, but by building on top of Tailwind it means that, when your project or resources grow and you want to move from (B) to fully customizing your style in (A), you will be able to write your individual little graphic touches in Tailwind instead of plain CSS.

[bennyp101]

I tend to use it with some sort of component system - vue/react/svelte - so writing the classes out once doesn't bother me.

I actually like it, as looking at the code I can see exactly what it does. 'btn-primary' doesn't convey anything to me. 'rounded text-sm font-bold py-2 px-3 bg-indigo-300' I know exactly what that is going to look like.

I also appreciate the removal of classes not needed if using a build step - much nicer to have a small css file that has exactly what you use, rather than a bootstrap style kitchen sink