The diff view on large PRs is pretty much unusable on all browsers.
The GitHub website is slow on Safari
161–170 of 367 posts
Re: The GitHub website is slow on Safari
#162GitHub has a great GraphQL API but a subpar UI. It's a great fit for Isograph! Anyway, if folks are interested, feel free to check out this conference talk (https://www.youtube.com/watch?v=sf8ac2NtwPY), where vibe code an Isograph app that consumes the GitHub API. TLDR, it is a lot easier to replace GitHub than you think, and it would make for a hell of a splashy side project.
Re: The GitHub website is slow on Safari
#163GitHub moved to a JavaScript rendering mode almost as soon as Microsoft bought it. Previously, I had been able to browse it with JavaScript disabled on my 2011 Mac Mini which Apple stopped allowing upgrades on past macOS 10.13. So even if I enable JavaScript, I can no longer browse GitHub, because they didn't bother to make their build compatible with browser versions as old as mine. It's hard to know which member of…
Couldn’t you install Chrome or Firefox?
Firefox 115 is the last version that runs on 10.12, 10.13, and 10.14 (also Windows 7 and 8). At this point 115 is 2 years old and GitHub is only tested on bleeding edge browsers, apparently.
So GitHub is usable but there are a number of UI layout issues and searching within a file is sometimes a mess (eg, highlighting the wrong text, rendering text incorrectly, etc. maybe that's true for all browsers. you're better off viewing a file as text in raw mode)
Re: The GitHub website is slow on Safari
#164I use Safari in my daily life, and I feel like 90% of the web apps I access are the worst crap in the world. At work, they decided to use Jira. Besides being slow, it consumes up to 2GB of RAM. Two gigabytes of RAM just for tickets? Ridiculous.
Re: The GitHub website is slow on Safari
#165Earlier quoted context omitted.
> And no, the problem is not "Rails" The problem is they abandoned rails for react. The old SSR GitHub experience was very good. You could review massive PRs on any machine before they made the move.
> The problem is they abandoned rails for react. Which, it seems, was a result of the M$ acquisition: https://muan.co/posts/javascript
fyi this page detects a hacker news referrer and sends you in an infinite loop. Have to open the link via copy-paste.
Re: The GitHub website is slow on Safari
#166The Github website is slow everywhere. It is truly a piece of shit software both in terms of performance but also UX/UI and everything in between. It's a product of many cooks and their brilliant ideas and KPIs, a social network for devs and code being the most "brilliant" of them all. For day to day dev operations is something so mediocre even Gitlab looks like the golden standard compared to Github. And no, the pro…
"The Github website is slow everywhere."
Perhaps it depends what software one is using
For example, commandline search and tarball/zipball retrieval from the website, e.g., github.com, raw.githubusercontent.com and codeload.github.com, are not slow for me, certainly not any slower than Gitlab
I do not use a browser nor do I use the git software
Re: The GitHub website is slow on Safari
#167Earlier quoted context omitted.
As someone who has worked in and with large orgs, the better question is "why does this always happen?". In large organizations "ownership" of a product becomes more nebulous from a product and code standpoint due to churn and a focus on short-sighted goals. If you put a lot of momentum behind a product with that mentality you get features piled on tech debt, no one gets enthusiastic about paying that down because it…
[flagged]
That the optimization pressure imposed by "capitalist masters" can lead to perverse outcomes does not imply that the optimization pressure imposed by communist ones doesn't, surely?
For instance, the GP could be a proponent of self-management, and the statement would be coherent (an indictment of leaders within capitalism) without supposing anything about communism.
Re: The GitHub website is slow on Safari
#168This thread has really opened my eyes to how much the world hates react developers, I am one. Unrealistic timelines, implementing what should be backend logic in frontend, there's a bunch of ways SPA's tend to be a trap. Was react a bad idea? Can anyone point to a single well made react app?
> a single well made react app What about Slack, the messenger? Umm, Discord? SoundCloud? Trello? Bandcamp? Spotify? If I keep going there are actually hundreds and thousands of well-made react apps.
Discord is well-known to be very buggy, e.g. the search function. Spotify is also very slow with thousands of placeholder skeletons. Remember that Spotify once had a very fast native player.
Re: The GitHub website is slow on Safari
#169The Github website is slow everywhere. It is truly a piece of shit software both in terms of performance but also UX/UI and everything in between. It's a product of many cooks and their brilliant ideas and KPIs, a social network for devs and code being the most "brilliant" of them all. For day to day dev operations is something so mediocre even Gitlab looks like the golden standard compared to Github. And no, the pro…
It is quite snappy in my Firefox on Windows.
Never had any issues with it.
The page the person on the issue had loading for 10s, takes almost 2s here.
Re: The GitHub website is slow on Safari
#170Earlier quoted context omitted.
Ideally, you automate a check like that. Because the answer turns out to actually be "humans are profoundly bad at that kind of pattern recognition." A computer will be able to tell that the 497th has a misspelled `CusomerEmail` or that change 829 is a regexp failure that trimmed the boolean "CustomerEmailAddressed" to "CustomerEmailed" with 100% reliability; humans, not so much.
Oh, certainly, didn't mean that you had to avoid using your IDE to autorename a variable yourself (to avoid the boolean issue) and diffed results to those of the PR Or that you had to avoid Ctrl+F "CustomerEmail" and see whether you had 1000 matches that matches the number of changed files or only 999 due to some typo. Or using the web interface to filter by file type to batch your reviews. Or... Just that in none of…
I envy your IDE being able to do a rename of that scale.
I work in a large C++ codebase and a rename like that will actually just crash my vscode instance straight-up.
(There are good automated tools that make it straightforward to script up a repository-wide mutation like this however. But they still generate PRs that require human review; in the case of the one I used, it'd break the PR up into tranches of 50-ish files per tranche and then hunt down individuals with authority to review the root directory of the tranche and assign it to them. Quite useful!)