Let's understand who is using js-ipfs! #2359
Comments
|
I’ve been collecting metrics for a while now and during that time I’ve found no compelling data point that would lead me to believe there is more Go adoption of IPFS than JS. In fact, I mostly find the exact opposite. For instance, I figured out a somewhat reasonable way to get Go dependencies today by searching for repos with Go files that contain “ipfs.” It’s not ideal, but is pretty much the best you can hope for given Go’s lack of package management. We have much better ways to get JS data, but just for the sake of comparison we can use the same method we use for Go. It’s going to undercount worse than Go numbers though, because Go’s lack of package management also means small dep graphs and this collection method misses anything past an edge dependency. But JS still gets roughly 4x the number of matches. Which shouldn’t be a surprise, this means we’re capturing a much larger market share of Go Developers than JS Developers given the disparity mentioned above. We seem to think people are using Go more, and that’s probably because it’s been the “reference implementation” for so long. But developers don’t care, or for the most part even know, what the reference implementation is. Developer choice has far more to do with the target environment, distribution strategy, and language familiarity, all of which give JS a sizable advantage over almost any language but especially Go. |
|
The sheer number of developers in the JS ecosystem (vs pretty much any other) and the ubiquity of JS runtimes makes not having a feature-complete implementation of js-IPFS a mind boggling concept to me. |
|
Some great places to start looking for the users:
Also good, although mostly used as a combination of JS client + go-ipfs - https://github.com/ipfs/js-ipfs-http-client/network/dependents?package_id=UGFja2FnZS0yMjk5ODk0MDU%3D I do invest time every once in a while searching through these sources and looking for new insights. It is as slow and cumbersome and it sounds, but I do find some really interesting uses and new use cases often making the effort worth it :) |
|
I think it is mainly used to produce dApps or censorship-resistant data |
|
Rerunning @mikeal's query in 2023, ipfs in go repos has 964 results, ipfs in js repos has 5329 results so it's swung even more in favour of JS. |
|
js-ipfs is being deprecated in favor of Helia. You can learn more about this deprecation and read the migration guide. Please feel to reopen with any comments by 2023-06-08. We will do a final pass on reopened issues afterwards (see #4336). This issue has been marked as a notable historical issue in #4336 . |
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:
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§ion=showcases_details
The text was updated successfully, but these errors were encountered: