Hello everyone. As we previously introduced the Mishka Chelekom library, we’ve been releasing many components for Phoenix and LiveView for some time now, and the count has reached a substantial number. We’re confident about DaisyUI and other libraries, and recently we’ve reached nearly 10,000 downloads.
Phoenix’s new version 1.8 has built-in DaisyUI support, and we want to support this library as well. However, we’ve encountered an ideological challenge that we’ve fully outlined in the issue below. We hope the community can help us reach a good solution.
The problem summary is that DaisyUI has its own specific HTML, as does Mishka Chelekom, and we’ve considered many aspects. If we want to fully support DaisyUI’s complete form with its HTML, we’d need to bring all components and convert everything from scratch into Phoenix components. If we don’t include the HTML, we can only use colors, shadows, and other elements, which certainly won’t visually resemble DaisyUI—full details are in the issue I’m linking.
We hope friends and colleagues will help us so that ideally we can fully support both DaisyUI and other custom design systems. We’re waiting for you dear ones.
If I was developing it I wouldn’t support DaisyUI. I look at Daisy as its own thing. It’s a way to quickly augment HTML. Chelekom is its own library so go your own way.
Use Daisy UI if you want as a base to build a base style for the library but don’t depend on it. Look how it supports its themes for example.
Your point is completely valid. My colleague and I, who have been working on this library over the past year, have thought a lot about the need to become more dynamic. That way, people can easily integrate their own design systems into ours just by using a config file or adjusting the CSS, without being limited to a single library.
I hope other colleagues and friends will also share their thoughts so we can reach a solid conclusion. If this version turns out to be the final phase of a major refactor, and we move past it, we can then enter a new phase where we start adding a large number of components to the project.
Design Systems is probably one of my favourite topics and I have probably “studied” hundreds of different systems, CSS frameworks and such! But you know why there are so many options? You can never please everybody. Some people will prefer something that looks good out of the box, some prefer something bare bones to style it themselves. It depends on the direction you want to go. Probably the option with the highest appeal is “looks good out-of-the-box but it is easy to customize”. This is what DaisyUI does well for example, since TailwindCSS isn’t really easy to build themes on top of out of the box (other than supporting light/dark theme of course). At the end of the day, you can achieve a lot by changing base/brand colour, fonts, radii, etc.
Absolutely, especially when the project is open-source and free. For example, the first admin panel I built with React made me realize that, despite the hype, libraries like shadcn are quite limited — I couldn’t even build a full dashboard page with it. On the other hand, Mantine was more complete, but editing it was hard since the source was buried in the library.
Eventually, I decided that in Elixir, my component library must be built directly into the project using the CLI. After a while, I noticed some developers don’t even care about functionality — they just want the same familiar UI everywhere, so I added tons of variants (e.g., base variant, which is super common in the JS community now).
I really hope this will be the last major refactor I have to do. If you look at enterprise UI libraries in C#, they’re not very stylish, but they offer 300+ advanced components. They’re not free, but they save you from constantly reinventing design systems.
As you said, there are many approaches, and you can’t satisfy everyone. Phoenix and its team have their own vision, and sometimes we just have to adapt. For instance, if I decide not to include DaisyUI, I need to clean up a lot of its CSS just to keep the project lightweight.
I really hope we can land on a stable solution — no more endless refactoring!
I would suggest you not to care about what the Phoenix include by default. At the end of the day, you have to maintain your code and the leaner the easier.
Something you might or might not support, is parity with the Phoenix Core Components in terms of naming and attributes. Not that you NEED TO, but if it replacing the core components with your library and an input just works without changing (at least much) code, it’s a bonus! I think it’s way more important than supporting DaisyUI or whatever it is, specially since it might change again in the future and your components library should be self contained in that regard, because again, design systems are a dime a dozen!
For example after installing the Mishka Chelekom lib as a dev dependency, user just needs to run this command and the command deletes the phoenix core component (import) line and replace with ours
But you know why there are so many options? You can never please everybody. Some people will prefer something that looks good out of the box, some prefer something bare bones to style it themselves. It depends on the direction you want to go. Probably the option with the highest appeal is “looks good out-of-the-box but it is easy to customize”. This is what DaisyUI does well for example, since TailwindCSS isn’t really easy to build themes on top of out of the box (other than supporting light/dark theme of course). At the end of the day, you can achieve a lot by changing base/brand colour, fonts, radii, etc. 
For example, the first admin panel I built with React made me realize that, despite the hype, libraries like shadcn are quite limited — I couldn’t even build a full dashboard page with it. On the other hand, Mantine was more complete, but editing it was hard since the source was buried in the library. 
After a while, I noticed some developers don’t even care about functionality — they just want the same familiar UI everywhere, so I added tons of variants (e.g., 
If you look at enterprise UI libraries in C#, they’re not very stylish, but they offer 300+ advanced components. They’re not free, but they save you from constantly reinventing design systems. 
