some solution toward identifying the good from the bad components

[nomilous]

As things grow I suspect a large amount of functionality duplication may arise, multiple components doing the same thing.

The resulting increase in the necessary effort required to select the most suitable component could potentially be lightened.

A rating system may achieve the desired result, but obviously require some effort on the part of the community.

Possibly more useful would be a count of the install base. Being that the install hits github, a parallel counter will need to be incremented by the installer.

[nomilous]

A possible curve ball: glory seekers hupping their own counters.

[ghost]

@nomilous why not github stars?

[nomilous]

nice, i believe that may just do the trick

[nomilous]

being kinda fond of efficiency and convenience, the stars being visible at http://component.io would be very useful

[nomilous]

being kinda lazy - i never even checked... :) appologize

[ghost]

:)

[jonathanong]

should be watchers IMO. i judge a repo by the number of people willing to get spammed by it.

[buschtoens]

@jonathanong has a point. How bout showing both? :)

[ianstormtaylor]

i think the three that are the most useful:

• stars (just pure i like this)
• watchers (like @jonathanong said, people who are okay being spammed)
• dependents (whether other components are using it. imagine if there are two similar ones, but one has waay more dependents then you should probably use it because then the chance that its already a "free" dep is higher)

random others: (less useful)

• pull requests
• downloads
• contributors

[jonathanong]

What I thought about last night was only showing components that are v1+ by default. This would hide a lot of components that are 0.0.x. It's not like versions actually mater, but it would encourage people to put effort into and bear responsibility of an API stable module vs spamming the registry with "cool ideas" which I even do probably.

Ex this would push @yields into releasing yields/select v1 :)

[ianstormtaylor]

haha, maybe we could just have a "stable" label that could apply to them. i bet 90% of the components in the registry are pre 1.0.0 and we shouldnt hide them all

[jonathanong]

yeah hiding is too extreme. for sure, we should add versions and maybe make all v1+ module versions green or something. we should at least give priority to v1+ modules in searches and stuff though.

[ianstormtaylor]

although tbh, i'd just start putting my components at 1.0.0 instead of 0.1.0 but nothing would change about the way i treat them

[jonathanong]

that's the point :) semver is easier when everything is v1+. if you break something, you'll have to bump to v2. otherwise, people will be like "meh" and bump to 0.2.0 instead. ~ doesn't really work < 1.0.0, but works much better > 1.0.0

i was thinking about the builder and duplicate versions since in the browser, you don't want two of the same module in a build. it would be much easier to resolve them if people actually use semver ranges, but semver ranges are a pain in the ass when everyone's modules are 0.0.100.

[jonathanong]

search is static now, so we have to do our own algorithms. feel free to improve the algorithm here: https://github.com/component/search.js