Live data from Hacker News

The GitHub website is slow on Safari

github.com

231–240 of 367 posts

Re: The GitHub website is slow on Safari

#231

Earlier quoted context omitted.

Whoever had a KPI for improving server performance and decreasing cost got their promotion that quarter, that is for sure.

Servers cost money, the client is free (and pays you sometimes)!

The client costs money too, opportunity cost.

Which, unfortunately, cannot be measured :( so no KPIs. Darn!

Its all fun and games until you cut quality over and over so much your customers just leave. Ask Chrysler or GE. I mean they must have saved, what, billions across decades? And for free!

Well... um... not free actually, because those companies have been run into the ground, dragged through hell, revived, and then damned again.

Re: The GitHub website is slow on Safari

#232
post #90

Earlier quoted context omitted.

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.

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

I don't think so, I think the problem is their devs work on tiny play pretend codebases or micro service architecture.

GitHub is big software, but not that big. Huge monorepos and big big diffs grind GitHub to a pulp.

Re: The GitHub website is slow on Safari

#233

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

> When native software is slow, it's bad software. When web software is slow, react is bad software. This is such a tired trope.

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.

Re: The GitHub website is slow on Safari

#234
post #84

Earlier quoted context omitted.

How much working memory/attention span is required to look through 1000 identical lines "-CustomerEmailAddress +CustomerEmail"?

Ideally, you automate a check like that. Because the answer turns out to actually be "humans are profoundly bad at that kind of pattern recognition." A computer will be able to tell that the 497th has a misspelled `CusomerEmail` or that change 829 is a regexp failure that trimmed the boolean "CustomerEmailAddressed" to "CustomerEmailed" with 100% reliability; humans, not so much.

We already automate that, it's called a compiler. The human review is just for kicks for this type of thing.

Of course some languages... PHP... aren't so lucky. $customer->cusomerEmail? Good luck dealing with that critical in production, fuckheads!

Re: The GitHub website is slow on Safari

#235

Earlier quoted context omitted.

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

I don't think so, I think the problem is their devs work on tiny play pretend codebases or micro service architecture. GitHub is big software, but not that big. Huge monorepos and big big diffs grind GitHub to a pulp.

GitHub runs a mostly monolithic architecture

Re: The GitHub website is slow on Safari

#236

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…

> …on my 2011 Mac Mini which Apple stopped allowing upgrades on past macOS 10.13. 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

The newer versions of macOS are also slower than the older ones, so that doesn't solve the actual problem.

Re: The GitHub website is slow on Safari

#237

Earlier quoted context omitted.

Well yeah, but just imagine how much money they’re saving by delivering a subpar experience!

They're not even saving any money. Syntax highlighting is a trivial workload, whereas the average SPA spends a lot of time in pointless roundtrips that have the server send more data down the pipe than the SSR equivalent.

Sending data is what’s trivial compared to compute… syntax highlighting is not trivial workload compared to that, you don’t know what you’re saying.

Re: The GitHub website is slow on Safari

#238

Earlier quoted context omitted.

fyi this page detects a hacker news referrer and sends you in an infinite loop. Have to open the link via copy-paste.

Firefox has a setting in about:config to only send referrer headers when navigating to links on the same base domain. network.http.referer.XOriginPolicy = 1

I believe this is enabled by default when using Enhanced Tracking Protection.

Re: The GitHub website is slow on Safari

#239

This thread has really opened my eyes to how much the world hates react developers, I am one. Unrealistic timelines, implementing what should be backend logic in frontend, there's a bunch of ways SPA's tend to be a trap. Was react a bad idea? Can anyone point to a single well made react app?

Been a huge React/SPA fan for many years, until the realization began to creep on me that building them was actually harder than building C++ MFC desktop applications (which I did back in the 2000's). Declarative markup was supposed to reduce cognitive load, but it now feels like the interplay between the declarative part of UI development (component markup) and the procedural part (event handling and state) has slowly morphed into something more complex than simplly developing the UI procedurally.

Back in the day (I was a junior dev) this was easier than grappling with React hooks today:

    BOOL CMainDialog::OnInitDialog()
    {
        CDialogEx::OnInitDialog();
        m_pPropertySheet = new CMyPropertySheet(_T("My Tabbed Dialog"), this);
        m_pPropertySheet->Create(this, WS_CHILD | WS_VISIBLE, WS_EX_CONTROLPARENT);

        CRect rectMainDialog;
        GetClientRect(&rectMainDialog);
        CRect rectPropertySheet(10, 10, rectMainDialog.Width() - 20, rectMainDialog.Height() - 20); 
        m_pPropertySheet->MoveWindow(rectPropertySheet);

        return TRUE; 
    }

Re: The GitHub website is slow on Safari

#240

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…

Have you used gitlab every day in anger? I don't think you'd feel the same if you have.

I both use gitlab, and run our gitlab instance for our company, with as many as 700 users.

I still love it! Works great, makes sense, is fast...

Post reply on HN