In #1563 there's a conversation about whether js-ipfs being at feature parity with go-ipfs is desirable.

A definitive conclusion about how ideal language A vs B is for use-cases X or Y is only one factor in determining whether we should have feature parity between our primary implementations.

It would be a more informed conversation if we had a better view about who is/prefers using js-ipfs and why.

The opportunity cost of a second-class JS implementation might be pretty big from both adoption and contribution standpoints, so even if we don't immediately prioritize js-ipfs feature parity, I'd like to understand the why more clearly, and to see us describe the current situation better.

@lidel had some ideas for doing dependency searches for discovering this set of users. Any other ideas?

For describing the current situation, I'm picturing something like a table on this repo's README that shows the differences between the two implementations when using on server, so that:

1. users who are deciding can be well informed
2. contributors who want to close the gaps can easily know where to get started

For context: Slashdata's most recent numbers for top programming languages by number of developers:

Full report: https://www.slashdata.co/free-resources/?id=developer-economics-state-of-the-developer-nation-16th-edition&section=showcases_details