Comparison with daisyui?

[rallisf1]

stwui seems very promising, kudos! I've been using daisyui for a while which is quite similar, delivers more on customizing looks and less on features as far as I can say compared to stwui.

What would your comparison be? Why should I prefer one over the other?

[N00nDay]

That's a great question. The biggest difference between the two is that daisyUI relies solely on class names to create and compose their components whereas STWUI relies on slots to handle this. I love Svelte but as a React developer I have fought slots (named slots for the most part) as Svelte has matured and with SvelteKit about to hit 1.0 I decided to challenge myself and embrace the slot if you will. Currently, there is built-in light and dark mode out of the box (still needs to be documented) and in the future, there will be documentation on how to override these themes and create your own if you like.

As far as deciding one over the other, I think it all comes down to preference. I struggle with mixing class composition and component composition. SWUI allows you to focus on getting a project up quickly and efficiently with easy-to-understand component architecture. By embracing the slot, developers can now have the freedom to change a component as they see fit. If you don't like the Card.Header for instance don't use it, simply insert your own component/HTML in the header slot and you are good to go!

In the future, I anticipate having a WYSIWYG version for each component that will allow a component to be written with one line and convert all the interior slots to props. This will hinder customization as all slot types will be predefined but will make development extremely faster if you do not plan on customizing the component from its original style and structure.

Hope this helps and thanks for starting the discussion!

[rallisf1]

Wow that was way more detailed than expected. Thanks for the info, and great work!

[N00nDay]

No problem. I try to be fairly responsive. Feel free to join the discord channel as well as I am always willing to help and answer any questions. After the next update, I am guessing there will be a lot of questions as removing the dependency on material icons effects almost every single component.

[rallisf1]

I use @iconify/svelte which supports a ton of icon libraries if that helps.

[N00nDay]

I like it as well. The process of walking back Icons as a first-class citizen is what is going to take some time. You can see my progress by viewing the Issue here: #39

My goal is to provide basic svg support. Meaning a simple hard coded file of just the icons you wish to use as an svg string. I prefer this as icon packages are anywhere from 2MB to 8MB which is a lot of overhead in my opinion. I prefer to just get the raw svg and use that. I usually use https://materialdesignicons.com/ or https://heroicons.com/ for svgs but most icon packages have an svg option. Then I am only adding icons to the project that are necessary and not including overhead that is not needed.

These icons will be available as first-class citizens to each component to control sizing and color or developers can use whatever slot the icon is supposed to go in and use the icon package of their choice instead. This should allow for greater flexibility on the developer's part but allow me to add simple options for those that are in the, "just let the library deal with it", mentality.