Commercial Plus Vesions

[sosensible]

Some of the offerings have a free version and then a commercial version on top. In those cases the selector would be better service if those were shown individually. This is especially important if the target use is for an open source library, and they need to know up front limitations in the free version because those features are only provided in the paid version.

[ddahan]

Hi there! Do you have a specific library in mind?

I think it's important to not mix components VS "blocks" as explained in the Read me. For example, PrimeVue has 100% of the components for free, and the premium version is for blocks, which are like "elaborated examples using these components". So they do have a premium version, but it does not add more components.

Note that this app focuses on components only and tries to not list blocks at all. That's why you won't see "Nav Bar" as a component, because it's considered to be a block.

Currently I don't see a tool with component limitation because only a subset of components would be free. But I agree if there is a such a library, a filter like this could be relevant I guess.

I agree the filter is not very useful currently, as it just removes Tailwind UI which is a paying set a component.

[sosensible]

I took a day to think through your response. Here are some things that came to mind. At Business of Technology, we think things through with this pattern. People-oriented business, business-oriented technology. We are all best served when technology is aimed at helping businesses best serve people. That runs from customers to staff, so it includes the developers.

• Blocks are apparently a thing. Should that be a selection in the mix vs. excluded?
• Some libraries are limited in original language docs. Yes, even perhaps English only.

We tend to refer to it as components and containers, a.k.a. blocks. We note some libraries call them layouts. Even in the same language, sometimes it can be bumpy.

In TailwindUI Pricing, you will see them declaring in each of the sections to the left "all of the components you need to build . . ." with the description of that section. They don't refer to any of their offerings as 'blocks.' Not many of the companies that offer components do reference blocks outside PrimeVue. That doesn't make you wrong, but your definition is not universal is the only point.

The name of your page is UI Lib Picker, and that, for most of your visiting audience, is what they will be expecting. It certainly isn't wrong for you to retarget to components, but the naming and the general community focus are going to be UI Lib, not just the non-block elements. And, as you stated, that means PrimeVue would be an issue for those of our fellow developers/designers looking to this site for answers.

NOTE: I believe Vuestic uses Tailwind based on these docs.

P.S. Wonderful site. I have done lots of similar research but your collection for passing the knowledge to others exceeds anything out there IMO. Already pointing people your direction.

[sosensible]

P.P.S. Found it... I knew there was another.

FormKit Pro offers this version with 11 Pro inputs * and counting.

[ddahan]

You got it right on the fact that every author has its own naming for things and that makes things more complex. As you said, as an example, Tailwind UI is mixing what I call components and blocks inside the same "component" name.

I had the same issue with naming components themselves. No Library has the exact same way to do. And that's why for each library, I need to dig further that what's it's stated in the documentation first page, to list what the library actually brings to people.

About the differentiation between components and blocks, you're right that some people actualy could look for these blocks. However, it seems complicated to list these blocs without creating a mess, as compared to components, blocks are 100x more subjective and can contain pretty much anything in there. For example, a "statistic page" could be anything.

Here is an idea I got in mind to improve the tool in your sense:

1. Have a new filter: Have blocks + this tooltip explanation: The UI Library, in addition to core components which listed here, propose "blocks". Blocks are more elaborated examples using the components, that can speed development up. Note that blocks are not listed here.

2. Remove filter about pricing (as it's usage is limited to remove TailwindUI from the list currently)

3. Add additional data on filter matching, about the pricing. Which means, for each library, you would get info on the card if something is free or paying.

What do you think?

[ddahan]

FormKit Pro offers this version with 11 Pro inputs * and counting.

Funny, I had this example in mind too :)

First, I think this library should not be included because it's a form validation tool first, that tries to lock you in by selling additional components that you'll need in the end. Selling stuff is not a problem, but locking people is, in my opinion.

Second, if this case happens, I guess my previous idea will be ok to deal with it.

[sosensible]

Right. You have a free flag. I was thinking that a paid flag would also be nice... the inverse of free because some companies only want a paid-for solution.

[ddahan]

I created https://github.com/ddahan/ui-libs/issues/18 based on your ideas. I close this one but feel free to reopen for additional discussion. Thanks!