Gothub: Alternative front-end for GitHub written with Go(codeberg.org)
codeberg.org
Gothub: Alternative front-end for GitHub written with Go
https://codeberg.org/gothub/gothub
67 comments
Calling this an alternative front end for GitHub sets all the wrong expectations. At least at the moment it’s just a very incomplete file browser for files on GitHub, and even the directory view doesn’t work — if you want to see a non-top-level file you have to manually construct the URL. There’s no commit view, no log view, no blame view, etc., and forget about search or issues.
Here’s an online instance in the US showing the VS Code repo: https://gothub.frontendfriendly.xyz/microsoft/vscode
I get frustrated by pull request tab performance on real Github - those turbolinks are buggy as hell. But I can’t see myself using Gothub because it doesn’t support PRs at all!
I get frustrated by pull request tab performance on real Github - those turbolinks are buggy as hell. But I can’t see myself using Gothub because it doesn’t support PRs at all!
For PRs reviewable.io is what I’d like to use instead of github, but while understandable the giant button it puts on the PRs makes it difficult to use as a personal secret frontend without company buy-in.
Shame, because just the tracking of comments which doesn’t suck would be a boon, to see nothing of seeing what’s actually changed since the last review beyond “this file has changed”
Shame, because just the tracking of comments which doesn’t suck would be a boon, to see nothing of seeing what’s actually changed since the last review beyond “this file has changed”
Thanks for the compliment masklinn!
Paying users can turn off the button on PR descriptions (and free users have some flexibility on where it goes). I hope you understand we can't provide the service free and secretly :D
Paying users can turn off the button on PR descriptions (and free users have some flexibility on where it goes). I hope you understand we can't provide the service free and secretly :D
[deleted]
file list doesn't work at all:
https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...
https://github.com/microsoft/vscode/tree/main/src
https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...
https://github.com/microsoft/vscode/tree/main/src
Shameless plug but if you're looking for an alternative UI for GitHub PRs, you may want to try CodeApprove (https://codeapprove.com)
Frustrations with GitHub's PR performance, limitations, and overall clunky UX are the main reasons people choose to use CodeApprove instead.
Frustrations with GitHub's PR performance, limitations, and overall clunky UX are the main reasons people choose to use CodeApprove instead.
What's the point of this? Github's UI seems reasonably well done and reasonably responsive to me. And it's not like you're removing a dependency, which is defensible.
I'm probably missing something here - what?
Now, if there were something like this but for Gitlab, whose UI is distractingly slow and just plain weird in a lot of ways, then I'd be very interested.
I'm probably missing something here - what?
Now, if there were something like this but for Gitlab, whose UI is distractingly slow and just plain weird in a lot of ways, then I'd be very interested.
A page such as this[1] requires javascript to be enabled to be viewable on github. Viewing any and all "/blob/" pages on github requires javascript to be enabled now. It didn't used to be this way ~1 year ago but github is slowly making javascript necessary on many pages for some annoying reason.
I could set up a redirect to the '/raw/' pages but then the syntax highlighting is gone.
The same page is perfectly viewable over plain html on gothub[2] though.
Github also seems to be hiding their "Assets" (binaries et al) on the "/releases" page for some projects behind javascript(especially older versions).[3] Something else that wasn't the case about ~1.5 years ago.
Would be great if gothub could unshackle the links to those as well[4], but that doesn't seem to work at the moment[5] .
This project appears to be a more performant(measurably so), more privacy friendly(as Microsoft won't have a record of your interest in certain projects) alternative front-end for "non logged in" github users.
I like it, but it still needs work.
[1] https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14...
[2] https://gh.bloatcat.tk/mackyle/sqlite/blob/18cf47156abe94255...
[3] https://github.com/mikf/gallery-dl/releases
[4] https://gh.bloatcat.tk/mikf/gallery-dl/releases
[5] https://codeberg.org/gothub/gothub/issues/74
The same page is perfectly viewable over plain html on gothub[2] though.
Github also seems to be hiding their "Assets" (binaries et al) on the "/releases" page for some projects behind javascript(especially older versions).[3] Something else that wasn't the case about ~1.5 years ago.
Would be great if gothub could unshackle the links to those as well[4], but that doesn't seem to work at the moment[5] .
This project appears to be a more performant(measurably so), more privacy friendly(as Microsoft won't have a record of your interest in certain projects) alternative front-end for "non logged in" github users.
I like it, but it still needs work.
[1] https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14...
[2] https://gh.bloatcat.tk/mackyle/sqlite/blob/18cf47156abe94255...
[3] https://github.com/mikf/gallery-dl/releases
[4] https://gh.bloatcat.tk/mikf/gallery-dl/releases
[5] https://codeberg.org/gothub/gothub/issues/74
Outside HN (and similar crowds) barely anyone has an issue with web pages running JavaScript. I understand the sentiment but don't think it's practical or useful/meaningful. That's how the web works, mostly. And that definitely does not justify the existence of this project -- the github website is generally fine and the use of JavaScript greatly enhances the experience especially after recent updates.
I have no problem with javascript. I think javascript can greatly add to the web experience.
"Add to" being the keyword there. Not "in lieu of".
You want to add javascript to enhance UI/UX outside the scope of what can be accomplished with plain html? Great!
You want to use javascript to add a feature that simply can't be done over plain html? Great!
You want to use javascript to hide a bunch of text on a public webpage, so those who have javascript disabled on their web browsers can't see the text, and will be forced to enable javascript, just to look at some text on a webpage? Unforgivably garbage design!
I will remind you that github used to work perfectly fine without requiring javascript merely a year ago. At least for basic perusal.
I think it is extremely silly design if I'm required to enable javascript, just to look at some text on a public webpage.
Again, nothing against javascript. But don't make it mandatory is what I'm saying, especially for casual browsing.
"Add to" being the keyword there. Not "in lieu of".
You want to add javascript to enhance UI/UX outside the scope of what can be accomplished with plain html? Great!
You want to use javascript to add a feature that simply can't be done over plain html? Great!
You want to use javascript to hide a bunch of text on a public webpage, so those who have javascript disabled on their web browsers can't see the text, and will be forced to enable javascript, just to look at some text on a webpage? Unforgivably garbage design!
I will remind you that github used to work perfectly fine without requiring javascript merely a year ago. At least for basic perusal.
I think it is extremely silly design if I'm required to enable javascript, just to look at some text on a public webpage.
Again, nothing against javascript. But don't make it mandatory is what I'm saying, especially for casual browsing.
What will need to happen that "but JS" stops being a self-serving argument?
If it performance poorly, as with anything else, let's hear it. But I do seriously wonder: Is there a sport in breaking a websites legs and point at it, while it's lolling on the floor?
I am not feeling it.
If it performance poorly, as with anything else, let's hear it. But I do seriously wonder: Is there a sport in breaking a websites legs and point at it, while it's lolling on the floor?
I am not feeling it.
It's both performance and quality.
Reinventing links detracts from the UX. You can't hover over the link and see where the link goes. Modifier keys often aren't respected meaning you can't open a link in a new window/tab with just one click. Fake links also break things like screen readers.
Reinventing the text widget means you're invariably going to miss something. Maybe you'll miss a "power user" feature like keyboard navigation. Maybe you'll miss something esoteric like rendering Chinese characters or find on the page. Maybe you'll break a rarely used feature like scrolling. Maybe you'll just display random characters.
To me it seems like a large part of the pain of requiring javascript is less about breaking nojs and more that devs are using javascript to poorly/partially reimplement key browser features. I'm reminded of the "Just normal web things" post the other day.
Reinventing links detracts from the UX. You can't hover over the link and see where the link goes. Modifier keys often aren't respected meaning you can't open a link in a new window/tab with just one click. Fake links also break things like screen readers.
Reinventing the text widget means you're invariably going to miss something. Maybe you'll miss a "power user" feature like keyboard navigation. Maybe you'll miss something esoteric like rendering Chinese characters or find on the page. Maybe you'll break a rarely used feature like scrolling. Maybe you'll just display random characters.
To me it seems like a large part of the pain of requiring javascript is less about breaking nojs and more that devs are using javascript to poorly/partially reimplement key browser features. I'm reminded of the "Just normal web things" post the other day.
Entirely on board. I am hoping we can critique concrete issues like these without resorting to guilt by association.
I see it is an instance thing like invidious or nitter which might be valuable for browsing github because it obscures you from microsoft but that makes it read-only because the moment you identify yourself you lose that benefit. That's assuming you can even do that on this. Basically I don't know because I never browse github. I am there for read-write purposes.
> reasonably well done
I guess. I've felt that Github's UI has been on a downward trend for a while, call it "enshittification" or "feature churn" if you'd like. A few things I can remember now: the redesign of the old dashboard; nothing improved, things just became harder to find, and maybe a designer at Github got a promotion. The dreaded "For you" tab that Github tried to force to be the default for a while. Profile "achievements". The latest changes to the editor/file browser have slowed down my workflows. Ah, and the latest UI refresh that shifted tabs around and forces a *hamburger menu on desktop viewports*.
There's a lot to like for sure; I still prefer Github to Gitlab. But there's also room for improvement, hence why people make these frontends to begin with.
I guess. I've felt that Github's UI has been on a downward trend for a while, call it "enshittification" or "feature churn" if you'd like. A few things I can remember now: the redesign of the old dashboard; nothing improved, things just became harder to find, and maybe a designer at Github got a promotion. The dreaded "For you" tab that Github tried to force to be the default for a while. Profile "achievements". The latest changes to the editor/file browser have slowed down my workflows. Ah, and the latest UI refresh that shifted tabs around and forces a *hamburger menu on desktop viewports*.
There's a lot to like for sure; I still prefer Github to Gitlab. But there's also room for improvement, hence why people make these frontends to begin with.
Well it's open source, that's a biggie.
It's not a GitHub alternative, it's a different frontend for GitHub.
Their point still stands. If Github makes a change you don't like to their UI tomorrow, there's nothing you can do. An open-source frontend provides an opportunity for you to customize the way you browse Github.
Check out the discussion threads where Github solicits feedback. The latest update is a regression in pretty much every sense.
In terms of performance, pages were slow to render because Github reinvented the textbox widget. Even searching within the page was fucked because redrawing was so slow. We're talking nearly a second of lag even though this virtualization bullshit was done ostensibly "so that the page is faster to load and snappier responsively".
The UI itself is increasingly cluttered with random widgets. A symbol explorer that cannot cope with non-default branches. A news feed of github.com related news that I can't dismiss. A personalized news feed full of repositories I'm not even remotely interested in. Ads for copilot.
The whiz bang text widget failed to account for multibyte characters. Emoji and non-Latin characters weren't displayed properly, and in one of the feedback threads an end user had to explain how strings work in Javascript.
The site itself is completely broken in the version of Safari that I use. Elements get positioned off the page.
There are tons of visual distractions e.g. that symbol explorer pops up when you click on some symbols, making text selection more difficult.
Keyboard navigation doesn't work (as it's not been implemented in their custom whiz bang text widget). I saw a few complaints that the whiz bang text widget randomly adds parens and indents and becomes blurry while scrolliing (as there are occasionally mismatches between the Github custom whiz bang thing and what the browser does).
The nav bar is a mess. The initial public release even eschewed any branch navigation, so if you scrolled down you couldn't easily jump to another or tell what branch you were on. Now they only hide branch navigation some of the time, depending on which size navbar you're allowed to have at the moment. As you scroll through a page the navbar itself jumps all over the place and changes size a few times.
The hyperlinks generated from Markdown are broken in a variety of ridiculous ways, the hyperlinks from the site itself are often no longer anchor tags (breaking accessibility and common sense).
Like everything else, code search is not branch aware. Given how much Github was hyping up the new search I really hope the ability to search a non-default branch is just hidden. But given how much the Github UX team loves scattering notification badges everywhere to highlight new features, I doubt it. Searching within the page got similar treatment and is more or less incompatible with the whiz bang text widget (Firefox only seemed to find things that were on the currently visible section of the page).
I've no idea if it's related but issue search has become nearly useless (for me). If I search for a term there's an awful good chance it isn't actually used in any of the issues returned.
My favorite comment was this:
https://user-images.githubusercontent.com/24989439/258012882...
For someone locked into a Github workflow, an alternative front end might be a nice thing to have.
In terms of performance, pages were slow to render because Github reinvented the textbox widget. Even searching within the page was fucked because redrawing was so slow. We're talking nearly a second of lag even though this virtualization bullshit was done ostensibly "so that the page is faster to load and snappier responsively".
The UI itself is increasingly cluttered with random widgets. A symbol explorer that cannot cope with non-default branches. A news feed of github.com related news that I can't dismiss. A personalized news feed full of repositories I'm not even remotely interested in. Ads for copilot.
The whiz bang text widget failed to account for multibyte characters. Emoji and non-Latin characters weren't displayed properly, and in one of the feedback threads an end user had to explain how strings work in Javascript.
The site itself is completely broken in the version of Safari that I use. Elements get positioned off the page.
There are tons of visual distractions e.g. that symbol explorer pops up when you click on some symbols, making text selection more difficult.
Keyboard navigation doesn't work (as it's not been implemented in their custom whiz bang text widget). I saw a few complaints that the whiz bang text widget randomly adds parens and indents and becomes blurry while scrolliing (as there are occasionally mismatches between the Github custom whiz bang thing and what the browser does).
The nav bar is a mess. The initial public release even eschewed any branch navigation, so if you scrolled down you couldn't easily jump to another or tell what branch you were on. Now they only hide branch navigation some of the time, depending on which size navbar you're allowed to have at the moment. As you scroll through a page the navbar itself jumps all over the place and changes size a few times.
The hyperlinks generated from Markdown are broken in a variety of ridiculous ways, the hyperlinks from the site itself are often no longer anchor tags (breaking accessibility and common sense).
Like everything else, code search is not branch aware. Given how much Github was hyping up the new search I really hope the ability to search a non-default branch is just hidden. But given how much the Github UX team loves scattering notification badges everywhere to highlight new features, I doubt it. Searching within the page got similar treatment and is more or less incompatible with the whiz bang text widget (Firefox only seemed to find things that were on the currently visible section of the page).
I've no idea if it's related but issue search has become nearly useless (for me). If I search for a term there's an awful good chance it isn't actually used in any of the issues returned.
My favorite comment was this:
https://user-images.githubusercontent.com/24989439/258012882...
For someone locked into a Github workflow, an alternative front end might be a nice thing to have.
I was kind of expecting it to be riddled with baroque embellishments, gargoyles, and bats.
If I play only Sisters of Mercy and Type O Negative while browsing gothub, is that close enough?
Gothic embellishments (the Baroque period was a couple of centuries later)
I too hoped for a gothic github.
Directory listing appears to be broken: I see pages without content when trying to browse directories [1]; observed on a few instances I tried, with a few repositories.
The code div is restricted to something like 50 characters, leading to line wrapping, if the browser window is at a width allowing about 150 characters; huge and unnecessary margins there, particularly awkward for code.
Looks like it may be nice and useful though, especially if it had a working search on top of browsing: GitHub's new search is tiring to use for skimming a new codebase now, and cloning large repositories for such skimming is inconvenient.
[1] https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...
The code div is restricted to something like 50 characters, leading to line wrapping, if the browser window is at a width allowing about 150 characters; huge and unnecessary margins there, particularly awkward for code.
Looks like it may be nice and useful though, especially if it had a working search on top of browsing: GitHub's new search is tiring to use for skimming a new codebase now, and cloning large repositories for such skimming is inconvenient.
[1] https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...
This seems to be due to [1], so the project is hardly demoable now.
[1]: https://codeberg.org/gothub/gothub/issues/124
[1]: https://codeberg.org/gothub/gothub/issues/124
Ahh as someone who has built several scraping applications, I feel their pain. It's a constant battle to keep your scraper working.
I need this because the new mobile-first Github design doesn't want to take up more than half the horizontal width on my Macbook's display. I have to zoom to 200%, at which point there is little content vertically, strain my eyes, or use the macOS system zoom to properly read anything.
To exemplify this, here's the same markdown from Gitea's home page on both Github and Gothub at the lowest browser zoom (Firefox) that fills the entire viewport.
Github: https://files.catbox.moe/pwvb3s.png
Gothub: https://files.catbox.moe/66idln.png
To exemplify this, here's the same markdown from Gitea's home page on both Github and Gothub at the lowest browser zoom (Firefox) that fills the entire viewport.
Github: https://files.catbox.moe/pwvb3s.png
Gothub: https://files.catbox.moe/66idln.png
FYI, your SSL cert isn't trusted on iOS...
I love seeing projects like this! In general I have always been extremely impressed with the coverage of GitHub's APIs. They're generally well designed, well documented, and available publicly around the same time as a new feature is announced. Which makes it possible to develop alternative UIs like this that aren't complete hacks. Very few other platforms have this type of coverage!
I've used the GitHub APIs on CodeApprove (https://codeapprove.com) to replace the part of GitHub that bothered me the most: Pull Requests.
I've used the GitHub APIs on CodeApprove (https://codeapprove.com) to replace the part of GitHub that bothered me the most: Pull Requests.
Oof, that doesn't look good. And it doesn't even work, when you click on a folder in the file listing it doesn't show anything. And if after that you click on "Back to xxx" you get an error that tries to be funny:
> Someone pushed to production. Just kidding, that's probably not what happened
Don't try to be funny in error messages, this is not helpful.
https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...
> Someone pushed to production. Just kidding, that's probably not what happened
Don't try to be funny in error messages, this is not helpful.
https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...
There is some problem:
- It does not display the contents of subdirectories if one is selected.
- Perhaps, add a slash at the end of directory names so that you can tell that it is a subdirectory more easily.
- Is it possible to list the available branches, issues pull requests, forks, etc?
- Can the style be changed? I don't like it to use its own width instead of using the window size.
- It does not display the contents of subdirectories if one is selected.
- Perhaps, add a slash at the end of directory names so that you can tell that it is a subdirectory more easily.
- Is it possible to list the available branches, issues pull requests, forks, etc?
- Can the style be changed? I don't like it to use its own width instead of using the window size.
GitHub puns are easy https://addons.mozilla.org/en-US/firefox/addon/githop/
In Gothub the only theme is dark.
I wonder if this is related to Game of Trees (Got), the Git-compatible VCS developed for OpenBSD developers: https://gameoftrees.org/
Why would an alternative github frontend be in any way related to a git-compatible VCS?
Maybe because the names both start with "Got" and both are related to Git.
you had me at "No JavaScript - pure HTML and CSS goodness"
No thank you, this isn't a front end replacement, it's just reading the API and displaying stuff in half ass kind of way.
the real problem with GitHub is the awful issue pages. For example look at this:
https://github.com/golang/go/issues/21498
they put this randomly in the middle of the page:
> 456 hidden items
> Load more
you click it, then you get this:
> 396 hidden items
> Load more
seriously, what is this? how is this better than pagination? with pagination, I can see the first page, and if I want to also see the last page (which this UI seems to be trying to do) I just click the link to the last page. what is so awful about pagination that we have ended up with this horrible excuse for a forum?
https://github.com/golang/go/issues/21498
they put this randomly in the middle of the page:
> 456 hidden items
> Load more
you click it, then you get this:
> 396 hidden items
> Load more
seriously, what is this? how is this better than pagination? with pagination, I can see the first page, and if I want to also see the last page (which this UI seems to be trying to do) I just click the link to the last page. what is so awful about pagination that we have ended up with this horrible excuse for a forum?
I personally don't want to go back and forth between pages when they include hundreds of comments. Inline loading of comments is the much better, smarter alternative. The last comments are loaded, you just gotta hit the page down key. The only thing that isn't loaded are the middle comments, and all you have to do there is tap load more comments link.
Yeah, a company that does over a billion API requests per day, they're not going to load 500 comments on a page, if you need that and I don't think you do, use the API, it has pagination...
Yeah, a company that does over a billion API requests per day, they're not going to load 500 comments on a page, if you need that and I don't think you do, use the API, it has pagination...
> Inline loading of comments is the much better, smarter alternative.
with pagination, each page has a fixed number of comments, which means an expected amount of memory/CPU/network transfer. with inline loading, everything is loaded into the current page, which means the CPU and memory use essentially become unbounded, so the more you load the slower it goes.
> The last comments are loaded, you just gotta hit the page down key.
that's not how GitHub works. as I mentioned in the previous comment, this hidden comments are in the MIDDLE of the page, so page down doesn't make any sense here.
> The only thing that isn't loaded are the middle comments, and all you have to do there is tap load more comments link.
this only loads 60 comments, so in the example page I linked you'd need to:
1. click load more
2. scroll down until you find the end of the 60 new comments
and then repeat this process 7 more times. with pagination, the page links are always at the bottom, not randomly in the middle of the page, making for faster navigation.
> Yeah, a company that does over a billion API requests per day, they're not going to load 500 comments on a page
no one is asking them to do that. that's what the current system allows for. I am asking for pagination, which would split all the comments across pages, which would only be loaded on request.
with pagination, each page has a fixed number of comments, which means an expected amount of memory/CPU/network transfer. with inline loading, everything is loaded into the current page, which means the CPU and memory use essentially become unbounded, so the more you load the slower it goes.
> The last comments are loaded, you just gotta hit the page down key.
that's not how GitHub works. as I mentioned in the previous comment, this hidden comments are in the MIDDLE of the page, so page down doesn't make any sense here.
> The only thing that isn't loaded are the middle comments, and all you have to do there is tap load more comments link.
this only loads 60 comments, so in the example page I linked you'd need to:
1. click load more
2. scroll down until you find the end of the 60 new comments
and then repeat this process 7 more times. with pagination, the page links are always at the bottom, not randomly in the middle of the page, making for faster navigation.
> Yeah, a company that does over a billion API requests per day, they're not going to load 500 comments on a page
no one is asking them to do that. that's what the current system allows for. I am asking for pagination, which would split all the comments across pages, which would only be loaded on request.
You're wrong, sorry, it's very obvious to see using your browser tools that GitHub is in fact requesting those records when the link is clicked versus loading every comment:
load_more?after_cursor
Where do we see cursors? Typically in pagination. So it's obvious if you want to see everything and load everything, you can do so and it's devoid of javascript so you can ctrl-f all day.
https://github.com/golang/go/issues/21498/partials/load_more
You get pagination in both API's, go write some code.
load_more?after_cursor
Where do we see cursors? Typically in pagination. So it's obvious if you want to see everything and load everything, you can do so and it's devoid of javascript so you can ctrl-f all day.
https://github.com/golang/go/issues/21498/partials/load_more
You get pagination in both API's, go write some code.
> You get pagination in both API's, go write some code.
you seem to be making my own point for me. you're essentially saying, the website is so terrible, that users need to write their own frontend to make it usable. I agree!
you seem to be making my own point for me. you're essentially saying, the website is so terrible, that users need to write their own frontend to make it usable. I agree!
No, I pointed out why you're wrong so you're moving the goalposts. You can get at all the data and instead of seeing the value in that, you rather complain about how terrible things are how stupid young people are. If anything, at this point I feel bad y'all are having problems clicking links.
> I feel bad y'all are having problems clicking links
They aren't even links. They are buttons that trigger JavaScript which makes a network request. That's quite different from an actual link that just loads some html
They aren't even links. They are buttons that trigger JavaScript which makes a network request. That's quite different from an actual link that just loads some html
Yeah, hiding the comments makes searching the issues nearly impossible. If your search term is in one of the hidden comments then it's click... wait... search... click... wait... search as you load all the comments. Imagine how much easier life would be if GH just paginated the comments.
No thanks. Infinite scrolling is never the answer.
No thanks. Infinite scrolling is never the answer.
I don't have that problem and if I did I would use the tools available to me to find what I wan't like the / command on every github page, or the gh cli tool:
Also, Lazy loading is pagination. You're getting the best of both worlds, you're not loading everything, and you never have to go back. I'm not understanding the problem people are having here at all.
gh issue view 21498 -c
Also, Lazy loading is pagination. You're getting the best of both worlds, you're not loading everything, and you never have to go back. I'm not understanding the problem people are having here at all.
the gh cli tool
There's already an issue search feature on Github, why shouldn't that be improved to return relevant search results?
My solution was to dial back my engagement with github (e.g. using a project's gitweb) and move to a different platform for hosting my own stuff.
Also, Lazy loading is pagination.
You think GitHub is just a website at this point? LOL. I do a lot of work in the terminal so I for one welcome a tool that enables productivity without having to visit a website. I know, it's a crazy concept, like wow.
When I use the search feature for text in the hidden comments, it brings me to that issue. As a pointed out below, you're also wrong and you can easily see that the comments are not loaded, are paginated, and that the loading of more comments only happens when you click the link to display more. The fact that it only displays 60 comments at a time and wont load any additional comments unless you click for more is why it's not infinite scrolling because after 60 comments, you're at the bottom of the page, unless you click, not scroll, for more.
When I use the search feature for text in the hidden comments, it brings me to that issue. As a pointed out below, you're also wrong and you can easily see that the comments are not loaded, are paginated, and that the loading of more comments only happens when you click the link to display more. The fact that it only displays 60 comments at a time and wont load any additional comments unless you click for more is why it's not infinite scrolling because after 60 comments, you're at the bottom of the page, unless you click, not scroll, for more.
You think GitHub is just a website at this point?
I do a lot of work in the terminal so I for one
As a pointed out below, you're also wrong
Look, you prefer the command line and that's great for you. That preference doesn't justify gimping the site.
> Also, Lazy loading is pagination. You're getting the best of both worlds, you're not loading everything, and you never have to go back.
you're getting the worst of both worlds. you cant see everything at once, the load more is in a random spot in the middle of the page, and its impossible to load everything at once.
compared to pagination, where you can jump to any random page you want. you just click the page number and boom it loads. I think we are looking at a culture clash, where younger people who dont have any actual experience with true pagination are trying to comment on it. if you had experience, you would know that its worlds better than whatever hellscape we currently have.
you're getting the worst of both worlds. you cant see everything at once, the load more is in a random spot in the middle of the page, and its impossible to load everything at once.
compared to pagination, where you can jump to any random page you want. you just click the page number and boom it loads. I think we are looking at a culture clash, where younger people who dont have any actual experience with true pagination are trying to comment on it. if you had experience, you would know that its worlds better than whatever hellscape we currently have.
You can, I posted the link in different comment, you can load everything, but you haven't bothered to look or explore, but using pagination means you never seen everything anyways. I don't think most people come across a 500 comment issue and need to start in the middle. They're reading top down and expanding as they get deeper into the conversation.
They're literally using pagination to display the issues, you can see it yourself. You think I'm a younger person because I disagree with you? That's classic. You're the only one I see complaining, I have no issues with it. If anything it sounds like you don't understand GitHub and you're unwilling to learn anything new or or even try to overcome your old and decrepit ways with tools that are readily available and simple to use. Whatever..., btw I'm well over the hill.
They're literally using pagination to display the issues, you can see it yourself. You think I'm a younger person because I disagree with you? That's classic. You're the only one I see complaining, I have no issues with it. If anything it sounds like you don't understand GitHub and you're unwilling to learn anything new or or even try to overcome your old and decrepit ways with tools that are readily available and simple to use. Whatever..., btw I'm well over the hill.
> You can, I posted the link in different comment
I am not going to prove your own point for you. if you have some link, you should provide it.
> You're the only one I see complaining
ooh yeah brother, great argument:
https://philosophy.stackexchange.com/questions/29811/identif...
> If anything it sounds like you don't understand GitHub and you're unwilling to learn anything new or or even try to overcome your old and decrepit ways
I am willing, I have been using the "load more" interface for as long as its been around. its terrible. from my EXPERIENCE with both systems, pagination is the more pleasant experience. with pagination, you can even link to a specific page, to direct someone to the beginning of an important sequence of comments. you might have this with the new system, but before you know it you're running into a load more again, making Ctrl+F useless.
I am not going to prove your own point for you. if you have some link, you should provide it.
> You're the only one I see complaining
ooh yeah brother, great argument:
https://philosophy.stackexchange.com/questions/29811/identif...
> If anything it sounds like you don't understand GitHub and you're unwilling to learn anything new or or even try to overcome your old and decrepit ways
I am willing, I have been using the "load more" interface for as long as its been around. its terrible. from my EXPERIENCE with both systems, pagination is the more pleasant experience. with pagination, you can even link to a specific page, to direct someone to the beginning of an important sequence of comments. you might have this with the new system, but before you know it you're running into a load more again, making Ctrl+F useless.
I don't think most people come across a 500 comment issue and need to
start in the middle.
b.) Yes, I often want to start in the middle. If I'm searching for a specific error message or class some of the search results include issues where that keyword was only mentioned in a hidden comment.
I agree with you. As someone who agrees with the other thread that the new pages for displaying code are a step backwards, I think that the issue pages are quite good.
Pronounced "goat-hub" ?
Goth-ube, obviously.
Any option to turn on Light Mode?
Anyone got a screenshot?
Here's an example repo: https://gh.bloatcat.tk/microsoft/vscode
Going into any of the directories there shows no contents unfortunately.
ex-maintainer of gothub, github changed their UI to make it require JS on the directory view route which meant we have to move from scraping to iirc fetching the data from a json endpoint or something.
The JSON data is included with the HTML. I did write a program that will parse some of it, but even then they sometimes changed a few things and causing the program to not work.
a front end for a front end...