Let's understand who is using js-ipfs! · Issue #2359 · ipfs/js-ipfs (original) (raw)
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:
- users who are deciding can be well informed
- 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:
