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

251–260 of 367 posts

Re: The GitHub website is slow on Safari

#251

Post by bigtones »

whstl wrote: post #216
veverkap wrote: post #191

Earlier quoted context omitted.

This is shockingly accurate - are you a Hubber? :)

What's that, a Github employee? Not really, I'm in an YC startup. But I guess the problem is that every single development position has been converging into this. The only times in my career as a developer where I was 100% happy was when there was no career PM. Sales, customers, end-users, an engineering manager, another manager, a business owner, a random employee, some rando right out the street... All of those wer…

If the PM was also an ex-developer and has both product management and development skills this happens a lot less. When the PM knows the Engineering and complexity and code debt cost of shipping a feature then they can self-triage with that additional information and choose not to send it to the developers or to consult with dev and scale it back to something more managable.

Its these professional PM's that have done nothing else other than project mangement or PMP that don't have an understanding of the long term dev. cost of features that cause these systemic issues.

Re: The GitHub website is slow on Safari

#252

Post by bythreads »

humpty-d wrote: post #214
lowwave wrote: post #203

Earlier quoted context omitted.

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

Various comments and links throughout the discussion of this post indicate that the problem is a mix of the sheer number of nodes and css. It has nothing to do with React or being a React SPA, which it's also not, unless you have some proof otherwise.

React and the most commonly used pattern inherently promotes an way to complex html Node structure and shitty css, especially if stuff like tailwind is used.

Now you CAN so it so that is not the case, but tbh i have never seen that in the wild -

Re: The GitHub website is slow on Safari

#253

Post by andrekandre »

andreagrandi wrote: post #76

Ok, so it's not just me. I was just struggling to assign a PR to a couple of colleagues and select a label (on a M2 Pro with 32 GB RAM!)

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

Re: The GitHub website is slow on Safari

#254

Post by baxuz »

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.

React is always the problem, as using it in a performant way requires you to basically eject from using it, relying on it only for syncing state, like video key frames.

There are of course performant react apps out there. What Steve did with tldraw is amazing.

However, the vast majority of the apps out there are garbage since the framework itself is terribly inefficient.

Re: The GitHub website is slow on Safari

#255

Post by wheybags »

futurecat wrote: post #8

GitHub Actions is such a pain to use just because of how sluggish it feels. I hope they’ll improve performance.

It also continuously fails to scroll down in the log view when watching output of a ci job live, and has done for years. It's so annoying that I made a userscript to force scrolling: https://github.com/wheybags/userscripts/blob/main/github_act...

Re: The GitHub website is slow on Safari

#256

Post by lmm »

EPWN3D wrote: post #229
gloosx wrote: post #145

Earlier quoted context omitted.

Slack is one the most slick and pleasant pieces of software to use. It's big success as well as the fact that it's acquisition cost was one of the largest software deals ever – tells of itself – it's certainly a fine piece of software made by fine engineers who used react and electron with a certain amount of dignity. People who rant about tools like react or electron affecting their performance just don't want to un…

Slack is the best of a bunch of trash options. That doesn't make it good. I shouldn't be able to accidentally select every widget in an app as though it were text. But with Electron apps, that's just normal. Slack puts a nicer shade of lipstick on the pig than Teams does, but the lips still belong to the same thing.

> I shouldn't be able to accidentally select every widget in an app as though it were text.

I absolutely should. I hate how many applications have a UI that won't let me copy-paste an error message to search for, much less a menu item; who could possibly have thought that was a good idea?

Re: The GitHub website is slow on Safari

#257

Post by moi2388 »

adithyassekhar wrote: post #228
culi wrote: post #222

Earlier quoted context omitted.

As someone who's worked with React professionally for years, it's honestly shocking how few React developers really understand memoization and when it needs to be used IMO it's the MAIN thing to understand about React—how it renders. Regardless, now I'm the one with egg on my face since the new compiler promises to eventually remove the need for manual memoization almost entirely. The "almost" still fills me with fea…

Is there a good article or something you could point us younglings to? I get that in react almost everything is reactive by default unlike other frameworks. I tend to add useCallback and memo to everything nowadays.

That only works if the inputs don’t change often. If they do, it’s actually a performance hit.

Re: The GitHub website is slow on Safari

#258

Post by varenc »

treve wrote: post #212
dham wrote: post #115

Everything is slower across every single facet of computing. Something is happening. I have a brand new Mac Studio M4 Max with 64gb of ram and every site is still slower than it was on a 2011 Mac Book Pro.

Web developers should be forced to use hardware that's roughly at the 10th percentile in performance of their user base, not the 90th. Alternatively, make performance a WCAG concern.

Chrome Dev tools, and hopefully others, have a performance monitor option that lets you throttle the CPU and throttle the network. It should be plenty possible to test performance of sites on simulated 10th percentile systems, but this just seems low priority.

Re: The GitHub website is slow on Safari

#259

Post by woutr_be »

bitbasher wrote: post #44

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.

Re: The GitHub website is slow on Safari

#260

Post by lmm »

fkyoureadthedoc wrote: post #178
sunaookami wrote: post #168

Earlier quoted context omitted.

Discord is well-known to be very buggy, e.g. the search function. Spotify is also very slow with thousands of placeholder skeletons. Remember that Spotify once had a very fast native player.

> Spotify is also very slow with thousands of placeholder skeletons. Remember that Spotify once had a very fast native player. Are you under the impression that the placeholder skeletons are there and slow because of React? How would a UI written in C++ get the data quicker from the back end to replace the skeleton with?

> Are you under the impression that the placeholder skeletons are there and slow because of React? How would a UI written in C++ get the data quicker from the back end to replace the skeleton with?

Regardless of how, the fact remains that the previous implementation of their UI did fetch and render the data from the backend significantly faster than the current React-based one does.

Post reply on HN