4 comments

[ 1.9 ms ] story [ 21.4 ms ] thread
Comparing JS frameworks and libraries was always a hurdle to me - its hard to find an unbiased up-to-date side by side comparison of the libraries one needs. Tons of blog posts and surveys come out every year trying to answer questions like "What framework to use in 2021", "Redux vs Recoil", etc. But all of them tend to have the same shortcomings: - biased - limited number of metrics and data sources - become outdated very fast - usually consider only 2-3 libraries

I wanted to create a tool that solves that problem

I quickly realised I need to solve the following problems/questions: 1. Moderated list of libraries vs automatic non-moderated (e.g. from Github, NPM). I didn't want to limit users in what libraries they can compare. At the same time I wanted to provide data from different platforms (npm, Github, Google Trends, etc.), the more different data sources the better. I couldn't come up with a solution how, for example, to map every npm package to every data source. Therefore I decided to have a moderated list of libraries and configure data sources for every library manually.

2. Scale nicely in both directions - horizontally (supported libraries) and vertically (charts and data sources). It was a pure technical problem and quite easy to solve - I created a configuration file where I configure charts and data sources for every library

3. Shareable comparisons. Selected apps are saved as url query parameters.

4. Find the right data sources for charts/diagrams. Sometimes it's easy to find the right api and use it, sometimes not. For example, I wanted to add a "Release frequency" (number of releases per year) chart. I thought it's easy to do and I just need to use Github api for that. Turned out not all js libraries provide release history data via Github api (not sure why). Then I had an idea of using jsdelivr.com data, but they don't have release dates. Finally I found an npm api which probably provides the needed data for all the packages, but it can take ~1Mb per package...

5. Do not abuse data sources and avoid "Service Unavailable" kind of problems. Currently every api call is cached for 24 hours (though it seems to not work the way I expect. Need to dive deeper here)

Ideas for the next charts: - build size (raw/minified/gzipped) - contributors - real usage of libraries (share of sites that use the library) - vacancies per technology - salaries per technology - licenses - use of stateofjs survey

TechStack: Vercel, Vue, Tailwind, Fauna (database)

Request for comments/questions Right now I'm keen to know if https://jsdiff.dev is something that can be interesting to others and worth building. What metrics users need the most. Any questions, comments and suggestions are very welcome and valuable.

the dip on the NPM downloads line chart felt as if no one is using these libraries any more
My simple way is pick your React / Vue etc carefully and then within that ecosystem pick popular libraries if they pretty much do what you need. Only go for offbeat libraries if they are the only ones solving your problem. I’d also avoid non typed libraries (ts) but that’s a personal thing. Searching through Reddit etc. for peoples experiences is also worthwhile.
Thanks for sharing you thoughts!

Your approach sounds very reasonable, especially when you start a new project and you are in charge to pick the tools.

In my experience things usually get more complicated for different reasons.

For example, you need to convince your upper management that your chosen tech stack is reasonable enough and visual comparison would help here.

Or you are in the process of migration a big application say from AngularJS to Vue and you can't use Vuex for state-management, because your data should be accessible from both frameworks at the same time. So you need to make a choice from a number of framework agnostic libs.

Or you'd like to switch a library (say from Enzyme to React testing library) and you need to convince other developers. In that case latest ThoughWorks Techradar could help if they put the already used library on Hold.

What also matters to me personally, among other things, is that the considered library should be actively maintained, preferably with a good number of contributors and frequent commits