Unlike celebrity culture, popularity in the open source world translates to actual impact on the web. As an author of a popular library, your code plays a direct part in how other developers structure their codebase, and -- depending on the library -- the end user experience.
And, yeah, impact/change/popularity (whatever you want to call it) is certainly a main reason behind releasing and maintaining open source software. Perhaps other dominant reasons include giving users differently opionionated alternatives that better suit their workflow, advancing the technical know-how of a field, and simply experimenting for expressiveness' sake.
Exactly. That's why we removed any mention of a "score" from the copywriting before launching. We realized how vague a score could be. We focus on site counts now, since they're raw/unfiltered data.
what's interesting about the work we've done on libscore is that it shows the end result -- whether a lib was actually ultimately used on a site. npm can tell you download stats, but that's where its data ends.
The problem was that fuzzy search would have been technically overwhelming to implement due to the size of our data sets (1 million sites * avg. # of leaked global variables). Also, it would have resulted in a lot of confusing matches because of how arbitrary JavaScript variable names are.
Keeping it to one-for-one case sensitive lookups was the only way to clearly express searching behavior and return accurate data every time. The downside is that we force people to read our homepage how-to to learn how to use it :)
One of the creators of Libscore here. I want to sincerely thank Stripe for making this project happen. I am still elated that they were willing to back this crazy idea of mine.
Libscore isn't perfect, but it sufficiently serves its purpose of competitive analysis. I've written more about the intentions of the project, including a thorough analysis of its downsides, here: https://medium.com/@Shapiro/introducing-libscore-com-be93165...
Fear not. Your performance concerns are mostly unwarranted (creator or Velocity here). Here are some articles to consider reading that help debunk this myth:
For what it's worth, Velocity is a fairly new library. I wouldn't have gone down the path of JavaScript-based animation had my research and testing demonstrated that it was appreciably inferior in any way.
The ramifications of this plugin are significant for front-end developers. It saves countless hours of dev time by preventing constant IDE <--> browser switching and repeated UI state reconstructing.