An algorithm to find right JS library to use
JavaScript has been the assembly language of the web era. There are millions of npm packages for developers to re-use. There are both huge, fat frameworks that requires months to learn and tiny, handy small code pieces that will save developers 10 minutes of boring work with 2 lines. For the same functionality, we can have tens or hundreds of packages to choose from. It’s not uncommon for developers to casually select and favor certain libraries without clear criteria.
Drawing from my past experience, I’ve come to appreciate the significance of professional decision-making in building high-performing teams. To make these decisions more systematic, I propose establishing a set of rules for answering the critical question: “Which package is the right fit for my project?”
So, what indicators can help us identify a great package to introduce into our repository? There are three key factors that provide valuable insights into a package’s quality:
Weekly Downloads: Packages with a high number of downloads on npm.js indicate active use by other repositories.
Recent Commits: GitHub repositories with frequent recent commits suggest ongoing development and maintenance.
Stars: A significant number of stars on a GitHub repo indicates popularity and interest within the developer community.
To compare between packages, we have to normalize their scores into right comparable scales. The best normalization algorithm would be able to satisfy the below three requirements.
Have a limit on upper and bottom. Let’s say between 0 and 1.
Able to accommodate very large numbers, million downloads per week.
The marginal contribution would be smaller and smaller.
Naturally, we would like to find a good function that draws a horizontal asymptotes curve. An arbitrary selection would be the following function curve:
f(x) = 1- (b)^x, where b is between (0 and 1)
This curve have a lot of great features. It starts from zero and gets closer and closer to 1, the marginal contribution of the numbers decreases.
The next step would be find the right b, and calibrate x cross the categories. The candidate of b can be 1/e. I admit this is out of instinct. Proof needed.
The calibration of x cross the categories would be: estimate how much times x is against the average in that category. For example, the npmjs on average have 20 download per week, then a package with 400 downloads per week would be 20. Average GitHub repo have 3 stars, so a package with 30 stars would be 10.
The total score is
3 - (1/e)^x - (1/e)^y - (1/e)^z
where:
x = package npm download count / average npm download count
y = package GitHub commits frequency / average git-hub repo commits frequency
z = package GitHub stars / average GitHub repo stars
Note, some of the values shall be logarithmic because of the scale.
Establishing clear rules like this can help minimize unproductive debates and arguments. It provides a solid foundation for meaningful discussions and improvements within your development team.
A package selector tool that can calculate this score would be useful. It is even better if it can display it in popular code editors like Visual Studio Code. Such a tool would undoubtedly prove handy in the world of JavaScript development.
