The way I see it the concern is not so much the inconvenience of removing these elements (although it’s not always a s simple as just deleting a file), but that their presence by default (and maintenance, which bears a significant cost) is actually a detriment to the ongoing evolution of the framework design. The discussion above about LV components was maybe not fully on topic of daisyUI, but it’s relevant to this specific point.
I’ve personally been frustrated in discussions with junior devs or newcomers to Phoenix who take some of the generator patterns as gospel when it’s a fairly established point that they don’t work well in every context and especially not in mature/complex apps. Their presence as “defaults” is not neutral.
What I’m suggesting with the LLM comments is that the adoption argument in favor of an easy, but not simple, out-of-box experience starts to fall apart in the presence of LLMs. I am sympathetic to the idea that these features helped adoption in the past, but going forward I don’t think this will be the case.
Unserious users, that is users who are just “trying out” the framework for an hour or so, are overwhelmingly going to use LLMs. Maybe a handful won’t, but they are a handful so they will not affect adoption.
Serious users, that is users who are either familiar with the framework or intend to be, can implement their own components. Maybe it would be nice for those users to have some quality pre-built components to choose from (which core_components are not), but in most frameworks that’s a third-party thing.
You might say “Phoenix doesn’t have a large enough community to sustain third-party component libraries”, but this is exactly @AHBruns 's point. Decisions like this drive those people, the ones with the skills to write those libraries, away. I think he’s right about that.
I also have to say that I think the value of “adoption” for Elixir’s future is extremely overblown. Would I like there to be a ton of jobs out there where you can use Elixir? Sure. Did Ruby on Rails gain a ton of market share due to the ability to deploy a decent looking blog (for the time) in 15 minutes? Probably. But that was when there was no RoR yet. Within 5 years it had mostly cornered that market. And as a Ruby dev at the time, I wasn’t completely happy with that, because suddenly I had to work with a bunch of people who liked Rails precisely because they didn’t actually like to solve programming problems (many barely seemed to care about Ruby itself). Despite the fact all but its most fanatical devotees mostly admit its best advantage is prototyping and scripting (I love Ruby and miss some things about it but there’s a reason I switched to Elixir for serious work as soon as possible), it remains dominant because markets reward a long list of things before innovation/quality, despite what most people would like to believe. I certainly hope Elixir can gain traction over the long term but I think the best for that is to lean on its unique strengths, and draw people who value it because it helps them build well designed solutions, rather than gift wrapping them for them. And I don’t think Elixir will ever make anyone as rich as it made some early Ruby adopters (not rich but I enjoyed some pretty cushy jobs for 10 years or so, long enough to build a nice resume, for which I am of course eternally grateful).
Any data to back that claim? Earlier you said “maybe not now but in 6 months”.
Is “we don’t need DaisyUI because Phoenix’s docs are great and AI will take over the world and erase humans from existence ” a position you are actually willing to commit to here?
It was not a strawman to me, but if you want to prevent such misunderstandings you could argue in good faith instead of placing the burden on me to filter out your sarcasm lol
And it’s all done by people trying out a framework? No. The overall figures are no proof that this specific activity is performed by LLM’s. For what it’s worth it could all be Questions, Simple Components and Refactors of large code bases.
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:
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 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.
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.
). Happy to take a first pass at a PR if it’s something you’d entertain.
