Suggestion to add new endpoint: /contributors

[chatterino]

Suggestion to add new endpoint: /contributors

[pajlada]

* longterm solution which will work as good with 100+ avatars in future

Have you checked that the current implementation can't handle 100+ avatars? I imagine that the troubles that the current implementation would run into would happen with a networked request too.

* no changes in current process of adding new contributors, everything stays in place

Something not changing is not a pro.

* no rebuild needed for updates, previous chatterino versions will also get up-to-date list

IMO not a pro, but I can see people feeling this way.

* current binary files will be ~400kb smaller (6%)

IMO not relevant

* probably minor build time improvement

Not relevant to users

* possibility to include other dynamic data, like current count of commits

IMO not relevant, but I can see people feeling this way.

My biggest con for this is the increase in runtime complexity. It means more things can go wrong for a feature that we already have fool-proof solution for. That enough should be enough to discourage this, but happy to hear any counter-arguments.

[Mm2PL]

no rebuild needed for updates, previous chatterino versions will also get up-to-date list

I see this as a con, to me the contributor list means who made the code currently running on my computer not what's in the remote git repository.

[kornes]

Have you checked that the current implementation can't handle 100+ avatars? I imagine that the troubles that the current implementation would run into would happen with a networked request too.

Im coming from standpoint that including avatar resources is wasteful overhead, today its 6% of binary size with just 15, but when it will go up to said 100, at same ratio it will be 2.5mb (or above 40%) just of content never seen in normal use. With current approach there is no ceiling for that growth, so at some point it would need to be addressed. I called fetching them over network longterm, because number of images wont affect binary size and all steps producing that binary.

Something not changing is not a pro.

Considered it pro because it doesn't change git history of added contributors which can have value for some ppl. Files would be kept in their current location and form, just not included in resources autogen.

If we are not interested in all goods coming from api due to extra complexity - i see your point here and agree.
What would all of you say about including just contributors.txt in c2 and fetching avatars from raw.github? It would be lightweight solution.
(I know this question belongs in other repo, but we can prolly come to conclusion here.)

[pajlada]

Have you checked that the current implementation can't handle 100+ avatars? I imagine that the troubles that the current implementation would run into would happen with a networked request too.

Im coming from standpoint that including avatar resources is wasteful overhead, today its 6% of binary size with just 15, but when it will go up to said 100, at same ratio it will be 2.5mb (or above 40%) just of content never seen in normal use. With current approach there is no ceiling for that growth, so at some point it would need to be addressed. I called fetching them over network longterm, because number of images wont affect binary size and all steps producing that binary.

I think it will need to be changed at some point regardless, once we reach a certain set of contributors we'll need to paginate/reduce size of images. Keeping all data in the repo/build itself lets us make that decision when it's time without having to think about forward-proofing an API.

... What would all of you say about including just contributors.txt in c2 and fetching avatars from raw.github? It would be lightweight solution. (I know this question belongs in other repo, but we can prolly come to conclusion here.)

I'm not as strongly opposed to this for complexity reasons since lazy-loading of images is something we need to have right either way, but we come to the point that was discussed in an issue in the c2 repo before. If we link directly to the users GitHub avatar, we remove our right to decide what pictures fit and don't fit in Chatterino
If we reupload images (e.g. by hosting them in the repo) that wouldn't be an issue.
Then the question would just be: Why? For the binary size is not a big enough argument to even think about imo. I've considered including an entire emoji set which would double the binary size to reduce network requests, having 30+ network requests fire when the user opens the About page just seems "meh".

[kornes]

If we link directly to the users GitHub avatar, we remove our right to decide what pictures fit and don't fit in Chatterino

change im suggesting is to fetch them from our repo (resoucers/avatars/), not user profiles.

I've considered including an entire emoji set which would double the binary size to reduce network requests, having 30+ network requests fire when the user opens the About page just seems "meh".

It would be cached after first open, just like we cache 200 emotes/emojis from Emote picker :D