It really doesn’t. I’m always shocked when people say this. There is good and bad tailwind and every single LLM that I have ever tried just gives you slop.
In fact it’s so bad that I have stopped using LLMs for any kind of frontend work. When you have to maintain that sloppy tailwind you are going to pull your hair out.
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:
So if we are going to claim those as truths, then we definitely need more data to back it up.
I believe the issue is actually about what flow is used for generation, unfortunately Phoenix uses the subtractional flow where generation comes with everything included, vs the additional flow where you have bare bones command that can be build up. It’s kinda ironic as plug’s design follows the additional flow.
The powerfully thing about additional flow is that we could still have similar commands as today. So it’s a win-win, instead of what we have today.
Serious was meant as a modifier of both the developer and the project in question, i.e. as an inverse to “throwaway weekend project”. It was not intended as some sort of pejorative. The point is that as one’s investment in a project goes up, the relative value of the pre-built components approaches zero.
The counter to this is that those weekend projects still matter, a lot, because they affect adoption. Built-in components make it easier to start a new project. If you scroll up far enough you will see that I was the one who made this point!
But further along I realized there was a good counter to that, namely that if you want to build a “weekend project”, something with low effort or investment, it’s increasingly likely that you will start with an LLM. LLMs do not have this cold start problem. They generate code when prompted.
As the percentage of LLM users goes up (and boy is it ever going up), the effect core_components will have on adoption will go down, eventually below the point where they are worth maintaining (this is a prediction).
Notice that this is not an argument for or against LLMs themselves.
truer words
You are still doing the same claims as before: that the pre-built components lack long term value or that core_components have no value for LLMs, but you haven’t addressed any of the core criticism I brought up:
“the builtin components lack long term value” is certainly not true in my experience
You have not verified the impact of CoreComponents themselves in LLMs. Removing them may make things better, worse, or indifferent. But we know for sure that LLMs can do a reasonably good job when CoreComponents are available, because we extensively tested it, but we know nothing about the opposite
Of course, you can just go ahead and claim that the above is your opinion, but that’s precisely my point. The discussion is unlikely to go anywhere if everyone is just stating their opinions without actual data to back any of their arguments. As I jokingly say: “if all we have are opinions, I prefer mine”. 
I never defended point 1 because the individuals I was discussing this with above (before LLMs were brought up) were largely in agreement that the core components aren’t a very good component system. This thread was a daisyui gripe thread lol.
I was disputing a very specific point (my own, really) that the components are bad but still good for adoption, on the grounds that widespread LLM use changes the calculus considerably (and this is a recent development).
Tbh I don’t really want to participate in a discussion on whether the components themselves are good. I don’t need the negativity and neither does anyone else. There were some good points made above which I agree with.
Maybe models would perform better with core_components for the time being. There is a huge space of tradeoffs to be had in practice, though, e.g. an LLMs.txt file might contain example components within it and so on. Personally I’m more interested in what would be directionally correct.
But I think what I’m trying to say boils down to “LLMs solve the cold start problem much better than core_components”, and I don’t really think that’s a controversial statement.
I feel this thread has become Tailwind vs Daisy when I had hoped the discussion would be centered around giving folks an option to not include DaisyUI when generating a new project.
How do you feel about adding a flag/param to the generator for excluding DaisyUI when creating a new project? Default everything stays the same, but for people who don’t want it they won’t have to manually pull it out.
I understand adding more options/flags is probably undesired, especially when manually pulling it out isn’t that much work. But if it’s quick and easy it may be worth considering (and I personally would benefit 
). Happy to take a first pass at a PR if it’s something you’d entertain.
This one thousand times. I’d prefer to have Catalyst integration a hundred times over DaisyUI.
If it would be possible to negotiate a 50% discount for Phoenix community I think it will end up as a win/win for everyone.
I’ve contributed to the templates before. They are EEx text templates that generate Elixir files.
If anyone would implement a --no-daisyui flag for mix phx.new, that means one of:
In either case, there’s also all the other mix phx.gen.* generators, which perhaps one might also ask for a --no-daisyui version.
Have a look at the repo. I personally think the added complexity to the templates is not worth pursuing.
Yeah that sounds like more hassle than it’s worth probably. I’ll check it out though. Thanks for the info!