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.
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..."
So, it was actually a bug in Safari's WebKit exposed by Github (which might be abusing it a bit anyway). But hey, since we are all web developers or web users, it's easier to shoot on the pianist (Github in this case)
Unfortunately this is the fate of most modern sites, they start off simple then they start bloating the website with social media and analytics. SV blokes don't care or notice on their $5k+ top of the line laptops but for everyone else it's an issue
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 problem is not "Rails" or [ insert any other tech BS to deflect the real problems ].
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
GitLab’s CI is miles better than GitHub’s. I think it’s telling that every place I’ve been at that used GH also used some 3rd party CI tool (which also sucked, but that’s par for the course), whereas places with GL seemed to manage with its native capabilities.
I went several years without having to interact with Github, I came back to it this year and it was truly shocking how bad it's gotten.
I had to alter basically every aspect of how I interact with it because of how fucking slow it is! I still can't shake the sense that it's about to go down or that I've done something wrong every time I click something and nothing happens for several seconds.
I once worked with an CTO who was under the impression that Rails was a major reason why the legacy app was so slow and demanded a rewrite in Java (that's what he knew). It deflected the real reasons - of completely incompetent product managers, management and inexperienced developers. The tech stack wouldn't matter if the product was being managed for over a decade by idiots.
This is likely happening in the new Pull Request experience only. If so, it's due to React. This is what happens when you use React for such large pages. "JavaScript is fast!" No, it really isn't. Especially not when you pile abstraction layer on top of abstraction layer on top of abstraction layer on top of abstraction layer.
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 short answer is: no, they don't. Google Cloud relied upon some Googlers happening to be Firefox users. We definitely didn't have a "machine farm" of computers running relevant OS and browser versions to test the UI against (that exists in Google for some teams and some projects, but it's not an "every project must have one" kind of resource). When a major performance regression was introduced (in Firefox only) in a UI my team was responsible for once, we had a ticket filed that was about as low-priority as you can file a ticket. The solution? Mozilla patched their rendering engine two minor versions later and the problem went away.
I put more than zero effort into fixing it, but tl;dr I had to chase the problem all the way to debugging the browser rendering engine itself via a build-from-source, and since nobody had set one of those up for the team and it was the first time I was doing it myself, I didn't get very far; Google's own in-house security got in the way of installing the relevant components to make it happen, I had to understand how to build Firefox from source in the first place, my personal machine was slow for the task (most of Google's builds are farm-based; compilation happens on servers and is cached, not on local machines).
I simply ran out of time; Mozilla fixed the issue before I could. And, absolutely, I don't expect it would have been promotion-notable that I'd pursued the issue (especially since the solution of "procrastinating until the other company fixes it" would have cost the company 0 eng-hours).
I can't speak for GitHub / Microsoft, but Google nominally supports the N (I think N=2) most recent browser versions for Safari, Edge, Chrome, Firefox, but "supports" can, indeed, mean "if Firefox pushes a change that breaks our UI... Well, you've got three other browsers you could use instead. At least." And of course, yes, issues with Chrome performance end up high priority because they interfere with the average in-house developer experience.
The end-user experience is not of any concern in modern tech. None at all. The only thing that matters is engagement hacking and middle managers desperately trying to look like they're doing anything with any value or meaning at all.
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
Another website that is so slow it's unusable is Stripe.
My CPU goes to 100% and fans roaring every time I load the dashboard and transactions. I can barely click on customers/subscriptions/etc. I can't be the only one...
Glad I’m not the only one experiencing this. The Stripe dashboard constantly freezes up for me, even registering a click takes 10-20 seconds. Often it will just go white. Incredible annoying.
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 so that overtime you pay off the dividends, without re-living through all the bugs you lived through 5 years ago that you don't recall the resolution of. Every rewrite project I've ever worked on, we run into bugs we had already fixed years prior, or the team before me has.
There are times when a total rewrite might be the best and only options such as deprecated platforms (think of like Visual Basic 6 apps that will never get threading).
What frustrates me more is that GitHub used to be open to browse, and the search worked, now in their effort to force you to make an account (I HAVE LIKE TEN ALREADY) and force you to login, they include a few "dark patterns" where parts of search don't work at all.
GitHub 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 the duopoly is more guilty for breaking GitHub for me, but I find that blaming both often guarantees success.
I could like, buy a new computer and stuff. But you know, the whole Turing complete thing feels like a lie in the age of planned obsolescence. So web standards are too.
> on my 2011 Mac Mini which Apple stopped allowing upgrades on past macOS 10.13
I know some people feel like Apple is aggressive in this respect, but that's an 8 year old version of a browser. That's like taking off all of the locks on your house, leaving the doors and windows open all while expecting your house to never have uninvited guests.
same except 64GB and M3 Max smh... takes literally minutes to open the "Labels" popup and make a pr... its completely unacceptable for a product like this...
Yeah, it is! Even for simple things, like opening a PR and searching in the combo box for the name of the branch to merge into. We only have like 40 branches. It should not freeze the tab for 30 seconds to search a list of 40 items.
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.
Safari is behind on web standards,
but often those standards are things designed and implemented by the Chrome team and pushed into standards later.
It's the Chromification of the web,
where the standard is "whatever chrome does".
It's much like the era of "Designed For IE" or "Works best in Netscape 2.3",
but now there's a thrice-convicted monopolist in de facto control of the standard.
95 comments
[ 3.0 ms ] story [ 96.7 ms ] threadDoes anyone have concrete information?
GitHub issues was so simple and now they keep shoving features into it.
Why has no one learned to not become Jira? You gotta say no sometimes.
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..."
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 problem is not "Rails" or [ insert any other tech BS to deflect the real problems ].
Too bad Phabricator is maintenance-only now https://en.m.wikipedia.org/wiki/Phabricator
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
Never had any issues with it.
The page the person on the issue had loading for 10s, takes almost 2s here.
I had to alter basically every aspect of how I interact with it because of how fucking slow it is! I still can't shake the sense that it's about to go down or that I've done something wrong every time I click something and nothing happens for several seconds.
Slow as hell and the Safari search function stopped working. I loaded the same url on Firefox and it was insta-fast.
The short answer is: no, they don't. Google Cloud relied upon some Googlers happening to be Firefox users. We definitely didn't have a "machine farm" of computers running relevant OS and browser versions to test the UI against (that exists in Google for some teams and some projects, but it's not an "every project must have one" kind of resource). When a major performance regression was introduced (in Firefox only) in a UI my team was responsible for once, we had a ticket filed that was about as low-priority as you can file a ticket. The solution? Mozilla patched their rendering engine two minor versions later and the problem went away.
I put more than zero effort into fixing it, but tl;dr I had to chase the problem all the way to debugging the browser rendering engine itself via a build-from-source, and since nobody had set one of those up for the team and it was the first time I was doing it myself, I didn't get very far; Google's own in-house security got in the way of installing the relevant components to make it happen, I had to understand how to build Firefox from source in the first place, my personal machine was slow for the task (most of Google's builds are farm-based; compilation happens on servers and is cached, not on local machines).
I simply ran out of time; Mozilla fixed the issue before I could. And, absolutely, I don't expect it would have been promotion-notable that I'd pursued the issue (especially since the solution of "procrastinating until the other company fixes it" would have cost the company 0 eng-hours).
I can't speak for GitHub / Microsoft, but Google nominally supports the N (I think N=2) most recent browser versions for Safari, Edge, Chrome, Firefox, but "supports" can, indeed, mean "if Firefox pushes a change that breaks our UI... Well, you've got three other browsers you could use instead. At least." And of course, yes, issues with Chrome performance end up high priority because they interfere with the average in-house developer experience.
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.
My CPU goes to 100% and fans roaring every time I load the dashboard and transactions. I can barely click on customers/subscriptions/etc. I can't be the only one...
Good to know others are feeling it too, hopefully it can get resolved soon. In the mean time, i'll try my PR reviews on FF.
Update: Just tested my big PR (+8,661, -1,657) on FF and it worked like a charm!
Clean code argues that instead of total rewrites you should focus on gradual improvements over time, refactor code so that overtime you pay off the dividends, without re-living through all the bugs you lived through 5 years ago that you don't recall the resolution of. Every rewrite project I've ever worked on, we run into bugs we had already fixed years prior, or the team before me has.
There are times when a total rewrite might be the best and only options such as deprecated platforms (think of like Visual Basic 6 apps that will never get threading).
What frustrates me more is that GitHub used to be open to browse, and the search worked, now in their effort to force you to make an account (I HAVE LIKE TEN ALREADY) and force you to login, they include a few "dark patterns" where parts of search don't work at all.
It's hard to know which member of the duopoly is more guilty for breaking GitHub for me, but I find that blaming both often guarantees success.
I could like, buy a new computer and stuff. But you know, the whole Turing complete thing feels like a lie in the age of planned obsolescence. So web standards are too.
I know some people feel like Apple is aggressive in this respect, but that's an 8 year old version of a browser. That's like taking off all of the locks on your house, leaving the doors and windows open all while expecting your house to never have uninvited guests.
In case you're one of today's lucky 10,000, OpenCore Legacy Patcher supports Macs going to back as far as 2007: https://github.com/dortania/OpenCore-Legacy-Patcher
https://github.com/vladimir-andreevich/firefox-macos-legacy