Option to pass a --no-daisy flag when creating a new phoenix project

I agree, I see the coupling with DaisyUI quite negatively.

I understand the need for a more comprehensive JS library, as many things are hard or impossible to do without a proper JS library (mostly animations).

But I always had a feeling of “understanding” of what was in my phoenix application, and with DaisyUI it seems way more opaque.

I am not against the integration, but I think the option should exist and perhaps even have an interactive prompt when generating a new app.

I thought I mistakenly created another topic so I deleted it. Sorry I didn’t see that you intentionally did split my reply into another topic.

No worries, it seems like a good candidate for a dedicated thread as you’re probably not the only one wondering where it fits. I’ve undeleted the thread - however we can delete it if you prefer

I understand the need for a more comprehensive JS library, as many things are hard or impossible to do without a proper JS library (mostly animations).

DaisyUI 5 is pure CSS, there’s no JS involved.

I thought it was a JS library to manage transition and such. My bad. But I still think it should be optional.

I whole heartedly agree that DaisyUI should be optional (and off by default).

Charitably, it was introduced because including it makes getting a super basic pretty looking CRUD app up and running marginally faster at the expense of long term maintainability and customization. Same logic that drove CoreComponents (which are, and I can’t say this enough, terrible both from a maintainability perspective and just a “how to make a good composable UI components suite” perspective).

The problem is that in no world are the 15 minute CRUD app weekend projects (which are the only projects that benefit from these decisions) the projects that should matter when it comes to decision making for a web framework. Making development of serious, complex apps that require maintenance beyond next week easier has to take precedence, and Phoenix just seems to be missing at every turn when it comes to this metric.

In that case, you should be able to justify taking an hour or so to remove daisyUI from the project and be done with it.

Personally, I don’t really like the default CoreComponents, but like so many other things in Phoenix, the framework doesn’t care what you use, and will chug along happily without daisyUI, CoreComponents, or whatever. They have to include something out of the box, and even if that something is not appropriate for everyone, the out-of-the-box experience is itself a teaching tool, which provides an example of what you can make with Phoenix. Use it, extend it, or get rid of it. The choice is yours.

I can definitely see the appeal of the pre-Tailwind CSS framework they used (Milligram IIRC?), but having something Javascript-based does highlight the capability of the built-in bundler integration.

The meaningless CRUD apps should not matter for making important decisions about framework design, but they do matter for making decisions about the “out of the box” experience (generators). Because that experience affects adoption. If it’s not easy to get started fewer people will stick around to build serious apps.

And as far as direction, well, what changes do you think Phoenix needs to better support “serious, complex apps”? Many here could easily predict what my answers to this question would be, but many would also disagree with my answers. There is a good chance you have a completely different idea of what makes an app serious or complex than I do.

I think what we really need, if anything, is more diversity.

So, I think I disagree on two points. The first is that that “have to include something” out of the box. No, they don’t. They could absolutely ship with no CSS framework, no CoreComponent, and generators that just generate everything (markup and styles) inline. It would provide the same value in terms of generating a functional but ultimately unmaintainable app quickly without any of the downsides.

Alternatively, Phoenix could ship with stock tailwind and a legitimate component suite (think shad/cn, but in heex) and generators that use said component suite.

As it stands it is choosing to ship with a non-generalizable component suite and a CSS framework that sacrifices maintainability and customization for initial development speed.

Second, your point about taking an hour to remove all these defaults is well taken, though it does beg the question. If the rational option for building a serious application is to start by undoing the framework’s defaults doesn’t that indicate they’re bad defaults?

This seems to be a perennial misunderstanding among web frameworks. Not all adoption is made equal and you get what you prioritize.

If Phoenix wants to be a framework for hobby projects, then so be it, but it can’t claim to be a framework for serious complex apps while simultaneously repeatedly sacrificing the developer experience of the people working on those type of apps for the developer experience of people working on hobby projects. Adoption of one comes at the expense of the other. Phoenix is choosing their user base, not just expanding it, with these decisions.

I should add that I mean complex in a pretty specific way. Specifically, I’m referring to apps that are complex in terms of Rich Hickey’s easy vs simple dichotomy (where an app that ranks low on simplicity is called complex). With this lens, I would push for defaults and tools that prioritize simplicity. DaisyUI is a good example of a library that is easy, but not simple (aka complex). Honestly, you could say that about a lot of Phoenix. It seems to consistently value ease of development over simplicity. I’d push for defaults that are simple. Tailwind is simple (not easy, but simple). Refactoring the live view component model to be simple (make components actually composable for example) would also be high on my list. Getting rid of layouts would also be up there. I could go on, but I want to keep this discussion at least a little focused and I see DaisyUI as one of the most egregious decisions when it comes to Phoenix valuing easiness over simplicity.