What do you think of Tailwind + daisyUI? (Poll)

Daisy is fine for simple stuff but their no-js stance makes some of the more advanced ui very clunky using checkbox tricks etc

I like daisyUI because it provides a set of components which are extensible with Tailwind. I have found it much easier to extend daisyUI’s components than I ever could when using e.g. Bootstrap. Conceptually, I think it definitely goes against the grain of what Tailwind stands for, but it gives me some sane options out-of-the-box, which I can then modify as needed.

Personally, I’m in no position to start composing my own class-soup components, so I like having daisyUI as a baseline. Plus, it has good theming support.

I don’t like that the new versions are so bleeding edge in terms of browser support, but that will work itself out over time. It is nice that I no longer need to use npm to install daisyUI, which greatly simplifies the dependency stack for my back-office applications.

Discussing Tailwind vs “Vanilla” CSS is not a binary discussion for me nor I won’t go into that here as I would need to write a book length explanation. I’ll just say both have their ideal scenarios and there isn’t a silver bullet for everything.

But regarding DaisyUI, I think it was a good choice as a base for Phoenix, it serves as a good base that is easy to extend or to rip out if not needed. I agree with @olivermt too.

Discussing Tailwind vs “Vanilla” CSS is not a binary discussion for me nor I won’t go into that here as I would need to write a book length explanation.

I originally had an “other” answer as an option, but I didn’t want to split the poll results too much.

I didn’t intend for the poll to be about “Tailwind vs. daisyUI”, but instead “Tailwind plus daisyUI”. As in, how users feel about the combination of the two. (That is my intention at least, but it’s up to the individual to decide how they feel about it.)

Well you should have included something for guys like me: “I have no idea what Tailwind or DaisyUI bring to the table, I just use them because the team decided on it before my time”.

I like this comment, as I fell like my frustration is not with tailwind or daisy ui but rather how entangled they feel in the generators. My frustrations are with the phoenix generators.

Yes, I agree with that. A generator like Laravel has would be a big plus for the ecosystem. I started some months ago exploring something like that and I have some ideas, but I think I would need some changes in Phoenix itself to make it as close to the base generators but more, so a superset of the generators, but right now there are some rough edges there.

I do not have a strong opinion on either, but I would prefer the default behaviour of the phoenix generators to not include them. Both are quite opinionated, and I think if you want to onboard people, you potentially ask them to learn two new additional frameworks.

Feels a bit force fed to me for a general MVC framework.

Like Tailwind, Daisy to me feels like a further step in the wrong direction.

But with that said I’m pretty sympathetic to the argument from the Phoenix team. This community simply does not have a large enough pool of talented designers to maintain our own components. And having things look good out of the box is needed for adoption. Given these constraints I’m having a hard time coming up with any other solution.

I think a better compromise would be to strengthen --no-tailwind into a new flag that simply elides all generated frontend code and leaves you with a bare project. No core components, no homepage, etc. Something that would require minimal effort to maintain.

I think that would do a lot to pacify those who want nothing to do with Tailwind or Daisy (a group of which I am actually a member, despite my recent comments).