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

31–40 of 367 posts

Re: The GitHub website is slow on Safari

#31

Post by scsh »

patrickmay wrote: post #21
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..."

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

If the project you're working on vendors dependencies it's pretty easy to end up with that many files being changed when adding or updating, even when trying to make as narrow updates as possible in one PR.

Re: The GitHub website is slow on Safari

#32

Post by bob1029 »

patrickmay wrote: post #21
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..."

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.

Re: The GitHub website is slow on Safari

#33

Post by whstl »

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 way it works in tech today is that there are three groups:

- Project managers putting constant pressure on developers to deliver as fast as possible. It doesn't even matter if velocity will be lost in the future, or if the company might lose customers, or even if it breaks the law.

- Developers pushing back on things that can backfire and burning political capital and causing constant burnout. And when things DO backfire, the developer is to blame for letting it happen and not having pushed it more in the first place.

- Developers who learned that the only way to win is by not giving a single fuck, and just trucking on through the tasks without much thought.

This might sound highly cynical, but unfortunately this is what it has become.

Developers are way too isolated from the end result, and accountability is non-existent for PMs who isolate devs from the result, because "isolating developers" is seem as their only job.

EDIT: This is a cultural problem that can't be solved by individual contributors or by middle management without raising hell and putting a target on their backs. Only cultural change enforced by C-Levels is able to change this, but this is *not* in the interest of most CEOs or CTOs.

Re: The GitHub website is slow on Safari

#35

Post by walthamstow »

mtmail wrote: post #30
sleepytimetea wrote: post #9

Earlier quoted context omitted.

They just pushed a new redesigned page for pull request diffs- must have bloated the DOM.

I still see a little "try the new experience" link on the PR diff page (top right of page) so the rollout might be gradual. I won't click.

I am such a masochist that I actually click those buttons. If it's good, great, if it's shit, I have time to adjust before they foist it upon me anyway

Re: The GitHub website is slow on Safari

#36

Post by ivape »

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?

I cannot fully explain to you how little companies care about quality and performance. Feature-mills are a real place.

Re: The GitHub website is slow on Safari

#38

Post by terminalbraid »

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 was done by some prior team you have no understanding of and it gets in the way of what management wants, which is more features so they can get bonuses.

Speaking up about it gets you shouted down and thrown on a performance improvement plan because you aren't aligned with your capitalist masters.

Re: The GitHub website is slow on Safari

#39

Post by celsoazevedo »

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

How long until those improvements reach users? I assume it requires an OS update or does Safari use something similar to Firefox and Chrome for faster updates?

Re: The GitHub website is slow on Safari

#40

Post by agos »

I experienced the same since I turned on the "new files changed experience". The fun part is that the first few weeks of the preview it was _worse_ then now. I am truly baffled at the lack of quality on such an important change
Post reply on HN