The GitHub website is slow on Safari

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

Embedding gists and not fully implementing using dark or light mode annoys me. It's there but it just always has the theme set to light with no way to override the value.

At the very least, I wish they set it to auto.

Ok so what's a good example?

Yes, I came here to say this exact thing. Also github search sucks bad as well as the way it shows diffs. My current client has just moved from bitbucket to GH and all the devs are up in arms.

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.

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?

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

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.

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.

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

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 the information about all the previous problems, then it is likely mistake.

The GCP tools are a performance disaster in both Chrome and Safari in my experience. It can be actively painful at times on some screen like the log viewer.

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

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

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

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.

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.