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

81–90 of 367 posts

Re: The GitHub website is slow on Safari

#81

Post by ants_everywhere »

terminalbraid wrote: post #38
ballenf wrote: post #19

Can someone who's worked in an org this large help me understand how this happens? They surely do testing against major browsers and saw the performance issues before releasing. Is there really someone who gave the green light?

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]

Re: The GitHub website is slow on Safari

#82

Post by chrisbrandow »

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…

It reminds me also of the original head of development of the Safari browser talking about at least the early days of building the browser. They had a rule that no commit of code could cause the browser benchmarks to get slower. And apparently he was maniacal about the rule.

I don’t know if that’s a good or realistic rule for most projects, but I imagine for performant types of applications, that’s exactly what it takes to prevent eventual slowdown.

Re: The GitHub website is slow on Safari

#83

Post by yrds96 »

Isn't the opposite? No one in this thread even cogitating how bad Safari is in terms of performance and supporting web standards? There's in one even partially blaming both. Github isn't the best example of a fast website, but if you can run it in Chrome and Firefox, even on rudimentary browsers like Palemoon (I tested) on decent hardware (even mobile), there's something clearly wrong on Safari.

Re: The GitHub website is slow on Safari

#84

Post by eviks »

ambicapter wrote: post #70
bob1029 wrote: post #32

Earlier quoted context omitted.

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

How much working memory/attention span is required to look through 1000 identical lines "-CustomerEmailAddress +CustomerEmail"?

Re: The GitHub website is slow on Safari

#85

Post by austin-cheney »

ballenf wrote: post #19

Can someone who's worked in an org this large help me understand how this happens? They surely do testing against major browsers and saw the performance issues before releasing. Is there really someone who gave the green light?

The primary goal in deciding upon a tech stack is how easily the organization can hire/fire the people who write the code. The larger an organization becomes the more true this becomes. There are more developers writing React than Rails.

Don't listen to the opinions of the developers writing this code. Listen to the opinions of the people making these tech stack decisions.

Everything else is a distant second, which is why you get shitty performance, developers who cannot measure things. It also explains why when you ask the developers about any of this you get bizarre cognitive complexity for answers. The developers, in most cases, know what they need to do to be hired and cannot work outside those lanes and yet simultaneously have an awareness of various limitations of what they release. They know the result is slow, likely has accessibility problems, and scales poorly, and so on but their primary concern is retaining employment.

Re: The GitHub website is slow on Safari

#86

Post by silvestrov »

ballenf wrote: post #19

Can someone who's worked in an org this large help me understand how this happens? They surely do testing against major browsers and saw the performance issues before releasing. Is there really someone who gave the green light?

In the old days we had the saying: "Nobody ever got fired for buying IBM"

Todays version is: "You will get fired unless you use React".

So every site now uses React no matter if the end result is a dog slow Github.

Bad developers looks at "what are everybody else using?".

Good developers looks at "what is the best and simplest (KISS) tool for this?"

Re: The GitHub website is slow on Safari

#87

Post by leosanchez »

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…

It is faster than GitLab, at least to me.

Re: The GitHub website is slow on Safari

#88

Post by joshmoody24 »

fleebee wrote: post #13
vintagedave wrote: post #2

I've read comments online (here on HN) that Github has been rewriting their UI in React and that it's got slower since. I have no knowledge if this is true or not (ie React -> speed direct correlation), and my own projects are small enough not to see any performance impact. Does anyone have concrete information?

I came across a blog post[1] (HN thread[2]) recently that sheds some light on the issue. The tl;dr is that the PR view can render over 100 000 DOM nodes, many of which are invisible inline SVG nodes, and SPA routing makes navigation a lot slower. [1]: https://yoyo-code.com/why-is-github-ui-getting-so-much-slowe... [2]: https://news.ycombinator.com/item?id=44799861

That blog post discovered that hard refreshing the page is faster than GitHub's SPA navigation, which led me to make this browser extension which makes GitHub navigation twice as fast:

https://chromewebstore.google.com/detail/make-github-great-a...

Re: The GitHub website is slow on Safari

#89

Post by adithyassekhar »

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

Earlier quoted context omitted.

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.

Honestly that's wild. This should be an option in their settings.

Re: The GitHub website is slow on Safari

#90

Post by Zanfa »

bob1029 wrote: post #15
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…

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

I’m pretty sure they used to do syntax highlighting on the server before and it was fast. Now they send down unhighlighted text that seems to choke the browser with anything but the smallest diffs.
Post reply on HN