it's bad idea for massive threads like 500-2500 comments

That's fair, maybe instead of on/off, the option could let each user set their preference of when to start hiding comments.

while it might be good for threads with less than 500 comments, it's bad idea for massive threads like 500-2500 comments, see why: "Load more comments" in issues and PRs needs to work better #5119 (comment), also it's currently possible to unhide all comments with userscripts if you need

Perhaps such extreme cases need a way to switch to a paginated view? Or perhaps a more intelligent/manual way of loading comment content similar to how sites like reddit work where you can click on the comments you want to read.

I wonder, though, if the performance issue you cite is the result of using the userscript you mentioned. If so, I then wonder if the userscript was the source of the performance problem -- trying to programmatically interact with "Load more comments" on the site to get them all loaded and running a separate comments request for each one. If that's the case, having a single "all comments" request option would likely solve that problem.

I do understand there is use case justification for partial loading from the end as well, though.

What % of threads have thousands of comments?

That seems like hurting the normal case to support an edge case. The suggestions here also include options for users to turn it on/off, or switching to a paginated view after n comments are reached. n could be configured per-repo and/or user, with a reasonable default like 75.

LoneFenris: Perhaps such extreme cases need a way to switch to a paginated view? Or perhaps a more intelligent/manual way of loading comment content similar to how sites like reddit work where you can click on the comments you want to read.

Yes, or this smart solution: https://github.com/orgs/community/discussions/5119#discussioncomment-15431886

iandunn: What % of threads have thousands of comments?
iandunn: That seems like hurting the normal case to support an edge case.

Regardless of %, they are still as much important as medium and smaller threads, and sometimes even more important, as they cover big and popular websites (therefore instead of counting their %, you should count their importance):

• https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue%20sort%3Acomments-desc
• https://github.com/uBlockOrigin/uAssets/discussions?discussions_q=%22issues+for+shorteners+%22+
• https://github.com/AdguardTeam/AdguardFilters/issues?q=is%3Aissue%20sort%3Acomments-desc

Info: since the current thread, there have been two duplicates created:

• Proposal: Allow loading more comments in either direction #10386
• Improve "Load more" functionality for long PRs

And now some funny example as a proof of "github collapsed comments issue" being pain in ass in big threads:

• 🟥 ALL YouTube issues: D-O-N-'T COMMENT without reading the 1st post🟥 uBlockOrigin/uAssets#20586 (comment)

I was asked by u/paintboth1234 on Reddit to discuss my YouTube issues here as well as on Reddit. I notice there are around 1200 posts in this thread, is there a way for me to read just ones from the last couple days without opening all 1200 posts?

Due to it, in big threads users are limited to read comments only from last 12 hours, it must be a joke from GitHub, the solution is simple: "Load more" button should be able also to load the last comments from the bottom, and not only from the top.

@AutistOctavius

Yeah, it's a pain. Almost as much of a pain as YouTube and their insistence that I watch their SSAP ads.

100% I'll never understand how "UX experts" thought this was a good idea

It's a regression/bug. I'm guessing that they've changed their rendering to replace all existing comments and apparently didn't consider that they need to maintain or restore the scroll offset.

Edit: Here's a bug report someone else already filed: https://github.com/orgs/community/discussions/172523

Looks like it has only been implemented for Issues:

as for PRs I still get:

without a menu to choose a direction.

(Though I was under the impression I had also seen it for PRs in the past but I am unable to reproduce that now)

That helps, but it's not that much of an improvement. It's 2 clicks to get there, and and I still have to do it multiple times to load more comments.

There's already the "load more" button for loading a small amount at a time. The new button should just load them all.

Maybe they're worried that folks won't realize that loading 2,500 comments might take a while, and could slow down or crash browsers on low-powered devices? I think that potential problem will be pretty obvious to most GitHub users. Those of us who are looking to show all comments are more likely to be maintainers, and are even more likely than the average user to be aware of potential issues.

Insufficient. It works only once. The second banner does not have the ⋯ icon.

Interesting indeed and weird, however it doesn't disappear always, sometimes the ⋯ button disappears, but sometimes not, looks like a random bug, or maybe there is some pattern...I've noticed that as long as "Load older activity" or "Load newer activity" buttons are used without using the main "Load more" button , the ⋯ button is always present, but once you begin mixing them with the main "Load more" button, and clicking all of them alternately, the ⋯ button sometimes disappear. The issue occurs on both Chromium & Firefox.

Yes, the issue already mentioned in the first comment still does exist, it's awful and burdensome, they should implement a nice solution like on the flarum forum: https://discuss.flarum.org/d/32901-staff-diary-v20-cycle - a nice slidebar at the right side which dynamically loads a given bunch of comments easily and fast. GitHub is 10 years behind...

10 years behind what? What is this future people are living in where they don't want information loaded and searchable? Why force the user to search via server side functions when their computers are powerful enough to search for a word on the page that is beyond the immediate scroll position? I don't understand how this is not "bad on purpose". Is this some kind of climate activism type thing - but they won't say it? Where loading the rest of the page when you didn't look at it is costing energy? Then just have a "load all" button - unless even the user intention to want to get all of the information should be opposed, limited or handicapped?

See: https://github.com/orgs/community/discussions/5119#discussioncomment-15434232

A separate server-side search that is scoped to within the current discussion/issue/PR would be nice.

Also, if this discussion had enough comments, that link to a specific comment would simply not work, which is a terrible experience.

andry81: It works at least for discussions. You have to enable the script and click the reload button.

But still doesn't work for Issues, so it works for Discussions, but not for Issues.

I didn't test it on Discussions before, because after it didn't work for Issues I assumed it doesn't work anywhere, as I expected it to work everywhere or nowhere. Not working on Issues, while still working on Discussions, is a bit unexpected and inconsistent, and it seems that you were misled by the same logic as well: you tried it on Discussions, and wrongly assumed it works on Issues. The userscript fooled us both.

andry81: You have to enable the script and click the reload button.

I know, you have to do the same to realise it doesn't work on Issues.

@garry-ut99

you tried it on Discussions, and wrongly assumed it works on Issues. The userscript fooled us both.

That's why I said "may be this can help".

@garry-ut99

I know, you have to do the same to realise it doesn't work on Issues.

You can try a fix: ludios/expand-everything#12

Yes, it works now.

expand-all-and-save-in-a-single-file

This could be addressed with a "print" button (to make an all-comments PDF) or using the REST API.