Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Let's understand who is using js-ipfs! #2359

Closed
autonome opened this issue Aug 14, 2019 · 7 comments
Closed

Let's understand who is using js-ipfs! #2359

autonome opened this issue Aug 14, 2019 · 7 comments
Assignees
Labels

Comments

@autonome
Copy link
Contributor

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:

programming-language-populations

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

@mikeal
Copy link
Contributor

mikeal commented Aug 15, 2019

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.

@achingbrain
Copy link
Member

achingbrain commented Aug 21, 2019

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.

@daviddias
Copy link
Member

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 :)

@alanshaw alanshaw added exploration kind/support A question or request for support labels Sep 3, 2019
@daviddias
Copy link
Member

daviddias commented Sep 13, 2019

Did a quick pass-through on the dependents of js-ipfs, here is a filtered list (still many more to review):

@hazae41
Copy link

hazae41 commented Oct 9, 2019

I think it is mainly used to produce dApps or censorship-resistant data

@achingbrain
Copy link
Member

achingbrain commented Jun 2, 2023

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.

@BigLep
Copy link
Contributor

BigLep commented Jun 3, 2023

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 .

@BigLep BigLep closed this as completed Jun 3, 2023
@github-project-automation github-project-automation bot moved this from 🥞 Todo to ✅ Done in js-ipfs deprecation Jun 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
No open projects
Status: Done
Development

No branches or pull requests

8 participants