Fret not! If you know where to start looking from things can get considerably easier. I happen to have some inside intel on the topic.
Besides "Google and pray" tactics you could try to use various package managers or discovery sites. The most known example of a package manager is NPM. That's the one that made Node.js so popular. Besides NPM you can find plenty of solutions designed for the frontend side. That is not to say NPM cannot be used for frontend as well, though. If you use browserify (Node.js modules for the frontend), that is the natural approach.In Finland Google returns npm.fi (Nakkilan Pyörä ja Mopo). Roughly translated it means "The Bike and Moped Shop of Nakkila". That's sheer lulz for natives.
As the vanilla web interface or terminal client for NPM might not be enough, there are some sites that use the same data and wrap it differently. The most known ones of these are node-toolbox and Node.js Modules. The former is closer to vanilla NPM but with some extra filtering whereas the latter is more like a popularity contest with a nice UI.
Given the API is open I expect we will see more interfaces such as these (perfect weekend project material. hint, hint). There is definitely room for innovation.
Bower, originally from Twitter, is an interesting case amongst frontend package managers. It integrates well with GitHub and is quite nice to use even. What makes it special is the discover service written by Sindre Sorhus.
As you might expect, you get a listing of modules and there's nice search functionality available. The problem is that as Bower components do not contain category metadata or tags, it is not possible to sort them in any meaningful way. You pretty much have to hope the author remembered to include the right words in the component description for the search to yield reasonable results.
Although Node.js modules often contain this metadata at the keywords field of
package.json, sometimes the authors might forget to use some relevant keyword. I think the ideal solution is to use something mixed. Perhaps a service should crowdsource this sort of metadata through its users. Later on they could be incorporated back into the package description.
Even though excessive fragmentation isn't particularly nice, it's still good to have these sort of discovery tools around. I do hope the authors gravitate towards a common format. In my mind that format is the one used by NPM. I suppose there must be some valid arguments against this and it's not up to me to decide anyhow.
Regardless of what package manager you use one of the biggest advantages they provide you is the way they deal with dependencies. It is nice to have that bit automated to some extent and documented the very least.
jQuery Plugin Registry and Unheap
The completely revamped jQuery Plugin Registry was launched a while ago. I haven't used it a lot personally and the selection is still quite limited. Over time that will change of course. As you might guess by now even these guys have a custom package format of their own. For package authors that is just extra work. Fortunately you can generate those package definitions with a bit of tooling in place.
If you are looking for something more graphical, consider giving Unheap a go. It looks just stunning and there is a nice categorization in place even. Props for that!
Steve Schwarz's JSPkg takes a bit different kind of approach. It expects that the library authors upload their packages to the service which it then hosts. This probably explains why the service doesn't seem that popular as it lists only a handful of packages.
JSwiki is a project of mine so I am very biased. It all started when an illustrator friend of mine asked for a list of game engines. I came up with one and it sort of snowballed from there after I posted it to Reddit. To make it easier to develop the content I moved it to a wiki format.
Later on I wrote an alternative UI for it as per Guillermo Rauch's idea. I use the wiki data and then attach it to custom structure using ghw, a tool I developed for this particular purpose. The site itself is hosted on GitHub Pages. Lately I've been using the tool for book publishing. Survive JS is an example of this.
Some time after I finished writing the alternative UI for JSwiki I was contacted by Michael Bodnarchuk. He had developed a service known as Symfohub and thought there might be some room for collaboration. And indeed there was. JSter.net was born as a result.
I think what made the original JSwiki a success had to do with two things. First of all it was open for anyone to modify. Although I contributed most of the content myself, at times you could see other people doing some work as well. Secondly I edited and tried to maintain a category system that made sense. It's not ideal but I guess it could be worse.
There are some very apparent limits at JSwiki. I managed to tackle some of these, such as table sorting, with the revamped user interface. Still, more complex functionality such as search was just impossible to implement this way. You can do only so much with static pages.
This is where JSter upped the ante. It utilizes categorization scheme and content inherited from JSwiki and takes it to the next level. Besides search we provide filtering within categories and provide access to more data per library than vanilla JSwiki.
In addition we maintain a blog and keep on improving the service continuously. I'm not saying it's the best service for discovering libraries but it's definitely one of the better ones out there. We're open for improvement ideas and collaboration schemes of course.
Google and pray
Use a package manager terminal client
Use a discovery service
Out of these I tend to favor 3. myself. Sometimes a listing blog post given by Google might be useful. I do believe the future is in discovery services simply because they're more likely to keep up to date than some random blog posts. That actually applies to this post as well. I guess someone needs to make a discovery service that keeps track of discovery services or something... Oh wait, JSwiki already does that. :)
I think we will see more discovery services in the future. They'll combine the data available in new ways and provide a better insight on the quality of libraries for instance. I hope I can contribute to this future a little bit myself.