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.

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

Or how much money they are capturing in investiments or corporate deals because of the tech stack

if you look at the thread, the explanation is not this easy, as much as it's satisfying to blame React (or any other single tech)

You're right. The technology is not necessarily flawed. It is more about the people who decided to use it and the way in which they used it.

We were very few to rant about it, 1 year ago: https://github.com/orgs/community/discussions/62372

Their "solution" was to enable SSR for us ranters' accounts.

That comment was about overall slowness of the site, not a specific issue on a specific browser.

Available data confirms that SPA tends to perform worse than classic SSR.

I'm pretty sure that if they rendered/updated the same insane amount of nodes with some other technology, for example PJAX like they used to do, performance would not be better

> Server-side rendering (SSR) flag has been enabled for each of you. Can you take a look, click around and let me know if this has resolved some of the usability issues that you've reported here?

The fact that they have this ability / awareness and haven't completely reverted by now is shocking to me.

exactly. I don't want to do a "no true scotsman" to defend React, but circumstantial evidence suggests that they wildly misused the tool

Agree you can shoot yourself in the foot with pretty much any technology. By design, it's much easier to be inefficient with SPA frameworks.

Honestly that's wild. This should be an option in their settings.

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.

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.

I guess if you say "we've made the UX worse" instead of "we've reduced costs but made the UX worse" to shareholders, they think of cost savings regardless.

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

I'll play devils advocate - does it save them some storage space or bandwidth in the CDN that delivers Github?

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

It is garbage even on my extremely high end desktop PC.

M4 macbook pro and almost unusably slow

A tool that lends itself to misuse so easily is a bad tool, period.

That's a good question, without looking into any of the code id say bandwidth cost goes higher when moving away from server side rendering since you have to send the code for client side rending to each client which connects.

> The problem is they abandoned rails for react.

Which, it seems, was a result of the M$ acquisition: https://muan.co/posts/javascript

This is actually unreal. Wow.

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

Lol I respect that https://muan.co/no-yc/

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

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

So PHP <6 was a great language?

We're not specifically blaming React. we're blaming their approach to React/SPA and how it caused a massive degrade compared to Github's Rails-based UX.

Github's code view page has been unreasonably slow for the last several years ever since they migrated away from Rails for no apparent reason.

Not once have I seen a site go from SSR to SPA and been pleasantly surprised. It always trends towards worse in responsiveness and overall UX.

I’m sure you could make something work better as a SPA, but nobody does.

The front-end is usually just a thin layer on top of a database, sometimes with backend services (queues/processing). Having a bad language on the front-end actually helped. You don't want to write code because of the bad language, you write less code, less code is less bugs. You had to be invested to increase the lines of code. It's like the hard chair of programming languages. If you don't want programmers to dwell there, bring the hard chairs.

The problem is that they deprioritized everything for more copilot bullshit.

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

While I agree about devs should be testing on slow devices, the particular target audience of the site generally have pretty decent machines (including two that I have) and there isn't much reason for the site lag. It's not really doing any 3D rendering with complex shaders or video filtering; it just shows changed lines in two files. That shouldn't lag.

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.

> When native software is slow, it's bad software. When web software is slow, react is bad software.

This is such a tired trope.

Only in the ideal world, where developers test results of their work on their machines. Test for real, with real db, not with empty or mocks.

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.

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.

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.

GitHub runs a mostly monolithic architecture

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.

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

MBA's ruin everything

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 -

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.

You can easily do this very fast in React if you don‘t fuck it up. They did fuck it up a bit.

Lol. If anything, Tailwind isn't shitty CSS (because it's a very limited number of classes) unlike the gazillion one-off classes that CSS-in-JS or even BEM encourages

Edit: here's a good investigation on a real-enough app https://www.developerway.com/posts/tailwind-vs-linaria-perfo...

Based tbh

Yes what's with his comment?

Tailwind is probably one of the best considering you can use Vite to literally strip out all unused css easily.

And I think tailwind v4 does this automatically

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.

I love the explanation in the linked site:

> Writing on the internet can be a two-way thing, a learning experience guided by iteration and feedback. I’ve learned some bad habits from Hacker News. I added Caveats sections to articles to make sure that nobody would take my points too broadly. I edited away asides and comments that were fun but would make articles less focused. I came to expect pedantic, judgmental feedback on everything I wrote, regardless of what it was.

https://macwright.com/2022/09/15/hacker-news

Which is true. Pedantism is the lowest form of pseudo-intelligence.

why do you say "easily"? it took them considerable effort to make that atrocity, I'm pretty sure. The fact that tens of people worked on this and yet this is the result is way more telling of the team and company culture than it is of the specific tool.

Have you not seen the internet these past decades?

So? You can still do a PR of 1 line and the diff will only show that 1 line.

A handful have replied to the two year old thread asking to have the same flag flipped. That seems unlikely to work, but why not ask?

Opportunity costs is something they are taught about in school but somehow seem to always forget about. I think it is more a question about incentives for the roles MBAs are usually hired into. Either that or the lack of knowledge of the actual product makes them too detached.

Yeah, if they read the actual link, the issue is CSS transforms on each line of code, not React.

React isn't the problem, the problem is literally every dev I've ever worked with who writes react good except for one or two don't understand or care how to write performant react code at all.

> Pedantism is the lowest form of pseudo-intelligence.

You can’t just lay this bear trap of an opportunity and expect me to not pedantically state that the word is either “pedantry”, the activity performed by pedants, or “pedantic”, to describe such activities.

“Pedantism” would be a philosophy or viewpoint that extols pedantry. Pedantism would be to pedantry as deontology is to rule-following, a justification of an activity. As such, pedantism would be a slightly higher form of pseudo-intelligence than mere pedantry.

But only slightly.

I code on ten year old laptops and use Bitbucket CLI in part because of all this.

Glad it’s not just me having faulty memory. I was reading a file - not a PR, just a file in our codebase - that was pretty large, like 15K lines, and it was dogshit slow. I was astonished, and thought I had remembered it being much snappier years ago.

Meanwhile, I opened a 100K line CSV in Neovim and while it took a couple of seconds to open and render highlighting, after that, it was fine.

You say that, until you’re one of the unlucky people who discover that cloud DBs are just cloud VMs in disguise, and those cloud VMs have network throughput limits.

A fun part of a retro at my company last year was me explaining to a team, “had all of your pods’ requests succeeded, the DB would have been pushing out well over 200 Gbps, which is generally reserved for top-of-rack switches.” Of course, someone else then had to translate that into “4K Blu-Rays per second,” because web devs aren’t typically familiar with networking, racks, data centers…

Not necessarily. Sharp tools are often sharp because someone needs it.

I’m not a frontend dev, and have next to zero experience with anything beyond jQuery, but an analogy is shell. Bash (and zsh, though I find some of its syntactic sugar nicer, albeit still inscrutable) will happily let you do extremely stupid things, but it also lets you do extremely complicated things in a very concise manner. That doesn’t mean it’s inherently bad, it means you need to know what the hell you’re doing, and use linters, write tests, etc.

> 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

Lots of developers are rather obsessed with writing good, performant code. The problem is rather that many project managers do not let them do these insane optimizations because they take time.

The only things that forcing developers to use slow machines will bring is developers quitting (and quite a lot of them would actually love to see the person responsible for this decision dead (I'm not joking) because he made the developers' job a hell on earth).

What you should rather do if you want performant software is to fire all the project managers who don't give the developers the necessary time (or don't encourage the developers) to write highly optimized code (i.e. those idiot project managers who argue with "pragmatism" concerning this point).

Who would even hire an MBA to improve such difficult to measurre things?

Maybe it will make a significant enough cumulative impact 5 years later that it can actuallly be noticed and defended in a meeting against other priorities.

But I’ve never heard of anyone hiring someone on minimum wage and deferring a huge bonus to 5 years later.

Even if it does makes a big impact, would anyone even take a such a job?

> because they take time

No they don't. It's literally just a skill issue.

Fast algorithms are often more complicated.

To give just one simple example: to get the textbook complexity bound for the Dijkstra algorithm, you need some fancy mergeable heap data structures which are much more complicated, and thus time-intense to implement than the naive implementation.

Or you can get insane low-level optimizations by using the SIMD instructions that modern processors provide. Unluckily, this takes a lot of time and leads to code that is not easy to understand (and thus not easy to write) for "classically trained" programmers.

Yes, you indeed need a lot of skills to write such very fast algorithms, but even for such ultra-smart programmers, finding and applying such optimizations need a lot of development time, which is why this is often only done for code parts that are insanely computation-intense and performance-critical such as video (and sometimes audio) codecs.

I added Pedantism to my spell checker, so now it's not red anymore. Checkmate.

Not to be confused with pedentation which is

> indenting or quoting yourself in a way that makes it look more authoritative

Serving static files off highly efficient, distributed CDNs is a solved problem. There's no "4K blu-rays per second" when you're talking about gzipped, highly cacheable text data.

If github has a million users visiting it per day on a FRESH cache, and all of them have to download at least 10 megabytes of text data (both of these numbers are far too high), you are at ... 0.015 "4k blurays per second". Yeah I think MS's datacenters will survive.

It's meant in a tongue in cheek way. Day to day I develop in C# and Typescript/React using all the latest bells and whistles. Long for the simpler times though. The time before product managers, Scrum and ticket driven development. All the tickets drive the complexity that maybe shouldn't exist. Hard to push back against feature requests when it's a one-way street.

A single-page app is not serving "static files". It might serve an initial bundle, but literally everything after that is dynamically generated. There's no way you could serve those responses via a CDN.

the most common cause is architecture, not algorithms

It should be the same speed as running git diff in your console. And it should support histogram style diff...

But taxpayers keep bailing them out... so how did they lose?

  > Which, unfortunately, cannot be measured 

This is such a subtle but important thing that so many people do not understand about data analysis. It's even at the heart of things like survivor bias[0]. Your measure is always a proxy and this proxy has varying degrees of alignment with what you want to measure.

I know everyone knows the cliche "The devil is in the details" but everyone seems to continually make these mistakes because nuance is hard. But then again what is a cliche if not words of wisdom that everyone can recite but fail to follow?

  > Its all fun and games until you cut quality over and over so much your customers just leave.

The alternative is you develop a Lemon Market. Which is a terrible situation for all parties involved. Short term profits might be up but these are at the loss of much higher long term rewards.

[0] You infer where the downed planes were shot through the measures you can make on recovered planes. But that is very different than measuring where downed planes were shot. You can't just take the inverse of the returned planes and know where to add plating from there.

To be fair, many programmers are part of the problem too. But then again, it is getting harder to differentiate some programmers from MBAs...