←back to thread

The GitHub website is slow on Safari

(github.com)
446 points talboren | 3 comments | 27 Aug 25 09:43 UTC | HN request time: 0s | source
Show context
PedroBatista ◴[27 Aug 25 13:10 UTC] No.45039192[source]▶
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 ].

replies(17): >>45039249 #>>45039365 #>>45039680 #>>45039841 #>>45040328 #>>45040430 #>>45041105 #>>45041125 #>>45041207 #>>45042280 #>>45042385 #>>45044131 #>>45046133 #>>45048521 #>>45050100 #>>45051138 #>>45062005 #
bob1029 ◴[27 Aug 25 13:14 UTC] No.45039249[source]▶
> 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.

replies(10): >>45039310 #>>45039407 #>>45039686 #>>45040388 #>>45041936 #>>45043631 #>>45048845 #>>45049190 #>>45051019 #>>45051373 #
Zanfa ◴[27 Aug 25 14:40 UTC] No.45040388[source]▶
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.
replies(2): >>45041029 #>>45041118 #
slt2021 ◴[27 Aug 25 15:33 UTC] No.45041118[source]▶
the problem is developers having fast modern machines.

if they were forced to use slow machines, they would not be able to put out crap like that

replies(6): >>45041255 #>>45041536 #>>45043882 #>>45046904 #>>45047482 #>>45051651 #
mrbombastic ◴[27 Aug 25 16:07 UTC] No.45041536[source]▶
M4 macbook pro and almost unusably slow
replies(1): >>45043661 #
lowwave ◴[27 Aug 25 19:04 UTC] No.45043661[source]▶
Ah the wonders of SPA! I know there are lighter ones, but it is not the first time hearing things like React being slow. Of course, when one start to do sntax highlighting on the client side....
replies(2): >>45044718 #>>45044747 #
1. Tadpole9181 ◴[27 Aug 25 20:27 UTC] No.45044747[source]▶
> When native software is slow, it's bad software. When web software is slow, react is bad software.

This is such a tired trope.

replies(1): >>45047513 #
2. const_cast ◴[28 Aug 25 02:02 UTC] No.45047513[source]▶
Its not really a trope, the opposite is much more common. People are much more quick to mindlessly blame SSR for slowness like with ROR or PHP.

The reality is both can be slow, it depends on your data access patterns, network usage, and architecture.

But the other reality is that SPAs and REST APIs just usually have less optimal network usage and much worse data access patterns than traditional DB connected SSR monoliths. Same goes for micro service.

Like, you could design a highly scalable and optimal SPA. Who's doing it? Almost nobody.

No, instead they're making basically one endpoint per DB table, recreating SQL queries in client side memory, duplicating complex business logic on the front and back end, and sending 50 requests to load an dashboard.

replies(1): >>45049456 #
3. whstl ◴[28 Aug 25 07:29 UTC] No.45049456[source]▶
React also has a class of problems that doesn't really happen in other types of apps: re-renders.

Even other frameworks like Vue.js, Solid or Svelte don't really suffer from it as much. It simply happens a couple order of magnitudes more often in React than any other framework.