Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The GitHub website is slow on Safari

github.com

Post reply on HN
Print view View original

61–70 of 367 posts

Re: The GitHub website is slow on Safari

#61

Post by bob1029 »

a-french-anon wrote: post #55
bob1029 wrote: post #15

Earlier 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.

We were very few to rant about it, 1 year ago: https://github.com/orgs/community/discussions/62372 Their "solution" was to enable SSR for us ranters' accounts.

> Server-side rendering (SSR) flag has been enabled for each of you. Can you take a look, click around and let me know if this has resolved some of the usability issues that you've reported here?

The fact that they have this ability / awareness and haven't completely reverted by now is shocking to me.

Re: The GitHub website is slow on Safari

#62

Post by agos »

bob1029 wrote: post #53
agos wrote: post #24

Earlier quoted context omitted.

if you look at the thread, the explanation is not this easy, as much as it's satisfying to blame React (or any other single tech)

You're right. The technology is not necessarily flawed. It is more about the people who decided to use it and the way in which they used it.

exactly. I don't want to do a "no true scotsman" to defend React, but circumstantial evidence suggests that they wildly misused the tool

Re: The GitHub website is slow on Safari

#63

Post by jayd16 »

PedroBatista wrote: post #11

The 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…

Ok so what's a good example?

Re: The GitHub website is slow on Safari

#64

Post by slipperydippery »

Nextgrid wrote: post #50
CafeRacer wrote: post #3

It truly feels like Jira.

It’s afflicted by the same disease: overuse of JavaScript and the need to give JS developers something to do. If you actually load up a ~2015 version of Jira on today’s hardware it’s basically instant.

I was reminded how fucked the modern web is a couple years ago when I encountered a so-fast-it-felt-like-local-static-html website dashboard that could have been a "web app", but wasn't.

It was being hosted on another continent. It was written in PHP. It was rendering server-side with just some light JS on my end.

That used to be the norm.

Re: The GitHub website is slow on Safari

#65

Post by blinkingled »

muglug wrote: post #5

Improvements merged within the last two days by the WebKit team: https://github.com/orgs/community/discussions/170922#discuss... For my sins I occasionally create large PRs (> 1,000 files) in GitHub, and teammates (who mostly all use Chrome) will sometimes say "I'll approve once it loads for me..."

Thanks, that is definitely a good sign - given the rendering engine monopoly state of Chrome+derivatives and lack of great momentum behind Firefox adoption we need Apple to actively keep Safari not just viable but great even if only on macOS/iOS.

Re: The GitHub website is slow on Safari

#66

Post by crinkly »

afandian wrote: post #49
crinkly wrote: post #7

Earlier quoted context omitted.

Wait until you plug it into JIRA, strap copilot and actions on it. Then you can have all flavours of hell at once. Our org has ground to a halt. A lot of the time we just break the branch permissions on the repo we are using and run release branches without PRs and ignore the entire web interface.

Just because I went to look it up, I thought I'd share. Looks like Atlassian removed the bit from the Terms of Service where you were prohibited from: > publicly disseminate information regarding the performance of the Cloud Products https://web.archive.org/web/20210624221204/https://www.atlas...

I didn't buy it or agree to them anyway :)

Re: The GitHub website is slow on Safari

#68

Post by nicce »

giancarlostoro wrote: post #56

The GitHub website reminds me of the first video in the Clean Coders series, where he points out that eventually devs want a total rewrite to "Fix" all the shortcomings, but GitHub from the perspective of most users had nothing UI wise that needed fixing. We all would have been happy with the UI as is. Clean code argues that instead of total rewrites you should focus on gradual improvements over time, refactor code s…

Rewrite is usually about learning about all the past mistakes and problems and designing your architecture in a way that you prevent all the previously known issues. It is iterative process on the design level. If you end up repeating all the same bugs, it went very wrong from the beginning. So if you don’t have the information about all the previous problems, then it is likely mistake.

Re: The GitHub website is slow on Safari

#69

Post by MBCook »

miyuru wrote: post #27

It not just safari, in firefox its slow too. I see loading spanner everywhere and even the page transition take ages compared to before. I am not sure what metric they are using justify ditching the perfectly working SSR they used before.

I’ve been having issues even in Chrome lately. All three browsers are dying evening the PR isn’t huge.

Re: The GitHub website is slow on Safari

#70

Post by ambicapter »

bob1029 wrote: post #32
patrickmay wrote: post #21

Earlier quoted context omitted.

That seems essentially unreviewable. If you can share without violating an NDA, what kind of PR would involve that many files?

"Upgrade solution from .NET Framework 4.8 => .NET 8" "Rename 'CustomerEmailAddress' to 'CustomerEmail'" "Upgrade 3rd party API from v3 to v4" I genuinely don't get this notion of a "max # of files in a PR". It all comes off to me as post hoc justification of really shitty technology decisions at GitHub.

It's not GitHub-specific advice, it's about reviewability of the PR vs. human working memory/maximum attention span.
Post reply on HN