I guess I am not a serious developer nor I build serious applications, given I don’t delete them.

EDIT: expanding on the above:

• Saying “no serious developer does X” is a “no true scotsman” fallacy. If that’s going to be an argument, then actually do a poll and understand how most people in the community use it (or not), based on their experience level, before claiming it as truth. Otherwise, it is very “convenient” to just claim that everyone who doesn’t agree is not a serious developer or not building a serious application

• If you are going to argue in favor or against LLMs for a given setup, then please do the job of generating 100 applications across different models, comparing the different approaches, and what works and what doesn’t. That’s what Chris did for the current approach, so we at least know it works for the current version

It is worth saying that, before we added Tailwind, there was a vocal part of the community saying that the lack of styled components was a detriment to Phoenix adoption. Once we adopted Tailwind, people said that the verbose Tailwind components pushed newcomers away. So @sevenseacat is right, whatever we do, we won’t please everybody.

And perhaps you are right, maybe lack of styled components doesn’t matter when we have AI, but:

• We don’t know how many people starting new Phoenix apps are using AI
• We don’t know if the models will do a better job without CoreComponents

So if we are going to claim those as truths, then we definitely need more data to back it up.

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.