throwaway29011 days ago
Definitely immediately noticed slowdown after the sidebar and other updates. I thought surely they would fix it quickly but no... And now it seems like the only way they support to browse!
It's basically impossible to view diffs now because they often fail to load, render correctly, or just are incredibly slow.
For example the file overview has 14(!) requests (/recently-touched-branches, /latest-commit, /overview-files/{branch}, etc.).
The issues list uses 5(!) requests to the GraphQL API. Didn't look in to why it needs five requests.
If we inspect the source for Github back in 2010 on the Wayback Machine[0], we can see that they were using jQuery like most sites of that time period.
[0] https://web.archive.org/web/20100115102310/http://github.com/ (interestingly, elan/plex shows up as a recently updated repo!)
Genuinely whoever was a part of pushing this rewrite should have been fired.
I guess what I’m really saying is that the internet would be a better place if you and others like you dialed down the rhetoric, dialed down the outrage, and dialed up the empathy.
Thanks for listening.
My hunch is that over time it became harder and harder for them to hire new frontend developers who didn't insist on building everything new in React and eventually they gave up.
1) The original web components proponents[1] there were very heavily into "vanilla" web components. Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API.
2) The GitHub Next team built their work in React because they required the ergonomics to move fast and they were operating independently from the production app teams. I think the first thing of theirs to be integrated was Projects, and they could probably show that their components had much better DX. Starting from the ergonomics argument, the hiring argument would take hold.
I've seen this happen a few times where web components teams believe that the whole point of them is to not have to use dependencies, hamstring themselves by not using a helper library on that principle, and then get web components as a whole replaced for a proprietary framework in search of ergonomics. If they had used an ergonomic web component helper library, they could have stuck with them.
The irony is that these transitions are usually way easier than a framework-to-framework migration because of web component's inherent interoperability. I still consider that a plus for web components: morally and pratically, technologies should be as easy as possible to migrate away from.
[1] GitHub was so into web components that they regularly sent representatives to W3C meetings to work on them, but a lot of the original team has left the company over the last 10 years.
GitHub did have their own declarative semi-reactice webcomponent framework. It's pretty nice!
https://github.github.io/catalyst/
It not at all coincidentally bears some resemblance to the (thinner, simpler) Invoker Commands API that has shipped in HTML (they share a main author):
There's also an impression from outside that the GitHub Next team also got a large amount of pressure to dogfood LLM usage, especially in new feature building.
There seems to be a visible ouroboros/snowball effect that LLMs are causing that they were trained so much on React code that's what they know best and because that's what they know best the goal should be to move things to React and React Native to take the most advantage of LLM "speed and productivity boosts".
I'm currently a pawn that feels about to be sacrificed in a cold war happening in my own day job over how much we should move towards React to make executives and shareholders happier at our "AI all the things" strategy. Sigh.
Some of the design decisions are also just baffling, like having "New Issue" in a small modal instead of just a full-screen page (only if you have templates set for some reason). Having less than half the screen being used is not helpful, and only going to reduce the quality of reported issues because it's just shit UX. Baffling. I genuinely wonder if the people designing/building this have ever used GitHub themselves (they reverted some of the other misguided "how on earth did you think that was a good idea?!" features, but not this one).
I have so many more gripes and bugs; clicking "show raw" generally works better for viewing code (or just cloning locally). It's just embarrassing. But it's all pointless to report because nothing gets fixed and it all just keeps getting worse.
GitLab was a "GitHub clone", but I guess now GitHub is turning in a "GitLab clone" by making everything a slow janky barely working mess.
Ah, good, so it's not just me, then. It's become unpredictable how many steps the back button will take you on GitHub. Or sometimes it'll just take you to a broken, perpetually-loading page. These used to be solved problems on the web.
They completely redesigned the code navigation to load it dynamically using React. One of the regressions introduced caused the entries to be duplicated when searching for a word using Ctrl+F. Their solution to address this issue? Decompose the source character by character, assigning each individual character its own distinct HTML node...
Needless to say, in addition to abysmal performance (it took seconds to display on my laptop), this also caused new problems (such as the inability to search for certain composite emojis). The worst part is that they seemed proud of their hack, since they wrote a blog post about it.
There is the "view raw logs" button which just opens a plaintext file that my browser loads and searches instantly (imagine that), but doesn't work for still-running jobs.
A web browser can render and search a boring pure-HTML syntax-highlighted source file just fine.
Anyway, it did work properly, now it doesn't. The response shouldn't be "you're holding it wrong".
The root cause of the problem is very fundamental to React and the nature of how the team designed the reactivity model. The TL;DR: React has an inverted model of state management [1].
In Vanilla, Vue, Svelte, Solid, any signals-based reactivity model, you explicitly opt-in to state changes by moving code into your reactive callback. In fact, in almost all of the code that you write, you typically explicitly opt-in to changes in state.
In React, you explicitly opt-out of state changes by moving code out of the reactive callback because the entire component function is the reactive callback (so any state in the path of that function that should not trigger a re-render has to be moved out via a hook).
This fundamental difference is what makes React hard to do well at scale because one needs to be very cognizant of where to place state inside a component and how to optimize for performance with memoization [2] (something Vue and Svelte developers pretty much never think about). The React team spent 2 years building the compiler to automatically manage memoization, but from the benchmarks I've seen, it's hardly made a difference.
In that time frame, Vue has been working on "Vapor Mode" [3] which bypasses the VDOM and brings it to parity with Svelte, Solid, and very close to Vanilla while still retaining a very easy to grok model of reactivity.
[0] https://youtu.be/INLq9RPAYUw
[1] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react/
[2] https://tkdodo.eu/blog/the-uphill-battle-of-memoization, https://tkdodo.eu/blog/the-useless-use-callback
[3] https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode/#patch-flags-in-vue
In signals-based platforms (Vue, Svelte, Solid), the signal targets specific subscribers and callbacks where the developer has opted in to state changes.
In React, though `useEffect` looks a lot like Vue's `watch`, they behave entirely differently because the entire component is registered as the callback.
The code examples in my second link [1] above are worth a glance because it makes it very obvious how similar these libraries are when glancing at the code, but how different they are in terms of how they deliver update signals.
If you look at the performance graph, you'll see that most of the time is spent on recalculating css styles. Unfortunately, I can't drill into it because I'm not getting the same problems on my machine. Maybe it has something to do with the 1000s of rendered DOM nodes - no idea, but it has nothing to do with reactivity.
My leisure laptop is an older macbook with firefox 78.15.0esr and a little over a year ago I stopped being able to view github files and issue discussions with it. I can still view READMEs most of the time but now I have to use chromium or another computer to actually read code without cloning the repo.
I know they could easily generate JS for older browsers if they cared to set the esbuild target.
IIRC they set the diff page to update entirely every reactive element in the page when some of this element change, instead of that one.
The previous AJAXed implementation had its haters, but at least it was very close to bare HTML on HTTP.
They could be using an internal beta version so they can "eat their own dogfood" before shipping.
This is something more recent.
I never quite understood why this didn't get fixed before by the way, because it really wasn't that hard. Usually when $big_corp takes over $small_outfit things get worse instead of better, due to overbearing $big_corp policy, culture clashes, leadership not really understanding what they bought, and things like that.
Whatever else can be said about Microsoft: in the year or two after they took over GitHub lots of things – small and large – got fixed or improved.
Both the node service and the website
it's a car crash in extremely slow motion
It's been like this for at least a year. Does nobody at GH actually use their own website?
I’ve been noticing GitHub’s UI getting sluggish and thought that maybe I’m off my rocker or it was a “my machine” problem, because Github wouldn’t do that… but I guess it’s pretty damn hard to prevent a bunch of devs, managers, and PMs from making changes to prove they should still be employed.
Which has been in Limbo since MS bought GitHub, is slow as molasses and is missing some fairly large features, yet MS also refuse to formally abandon it.
It's very frustrating to have a tool that has spent 15 years fading into the background of reliable infrastructure become an intrusive, distracting mess.
After a couple months with jujutsu it's almost completely replaced my use of git. It’s a lot to hope for, but just as jujutsu surveyed a couple decades of VCS to syncretize a huge improvement, I do hope someone will do the same for collaborating with jujutsu. GitHub PRs feel very unfortunately frozen in amber because their popularity makes it very hard to fix the core UI design problems it has with multiple tabs, incoherent timeline, edited commits, missing "8 more comments", and now a steady drip of SPA jank.
The big remaining feature of GitHub is the network effect of coworkers and potential contributors already being logged in, and there could be a race between a competitor neutralizing that with bidirectional sync (see git-bug) and GitHub getting their usability problems sorted. Microsoft's legendary resistance to breaking changes means there's a very big window available.
You'd think clicking on author's name in commit log view would bring you to their profile — social coding, after all — yet it simply filters the log by author.
Just checked, apparently, they do have a tooltip popup in "Commits" log view to go directly to the author, but who has the time to wait 1s until the tooltip's appearance? Clicking on the name simply filters commits by the author, clicking again, just reloads the same page you're already on — but, hey, at least they didn't break the URL addresses yet!
Which is crazy given how little interactivity and DOM state a site like GitHub actually needs to manage.
It would be a really great feature if it worked correctly.
https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md
Disappointing devs still try to justify javascript on large sites like git.
Front End Engineer roles pay less than general Software Development Engineers at pretty much every FAANG and so you see a lot of FEEs want to transition. Not much senior talent gets kept in that kind of pipeline.
Not in my experience for the last 5 years, looking at two job ads and comparing the salary range, they are usually the same. Which FAANG still does this?
Note that I didn't say anything about their _current_ incarnations…
Your discoverability will drop to close to zero, and Actions are trickier to set up. Plus, you'll have to come up with a backup plan.
But, you'll be hosting your code on your machine, Microsoft will be out of the loop completely, and you won't be feeding the AI monsters if your repo's are set to "private".
It's different from GitHub in many ways (no user-generated content, day-by-day mostly static pages), but it's interesting to see how good a browsing experience can be. It makes sense given that their value as a company depends so much on making it quick and easy to find exactly what you need.
Too bad that everything has to be rewritten in React.
Gitpatch is a bit different. It implements a new storage backend and Git library from scratch. It also uses patch-based model for code review vs pull requests, where specially-named branches are used to submit patches and patch stacks.
Btw, I worked at GitHub for 3 years and they are very aware that slowness is a big issue throughout the whole product. There was a year long cross team effort to improve things but the main goals were not achieved IMO and it shows.
Good question. I don't have now right now but I can prepare one soon. In any case I store zero information from users. When you are logged in traffic goes directly from your browser to GitHub.
This comes to solve the problem of the terrible UX in the most widespread git service. I won't dare to try to convince my whole team, or company, to migrate to GitLab, but this can be easily adopted.
GitHub is one of the few companies where performance is actually commented upon, but in the vast majority of cases stuff just gets slightly slower and nobody cares.
GitHub pull requests were down - https://news.ycombinator.com/item?id=44799494 - Aug 2025 (113 comments)
Performance, usability and overall adaptability to the phone size, it is incredible how a native app can be that good.
I wish the Web UI performed as well as the native iOS app.
It’s built in Vue. My first 5 or 6 attempts at writing the diff viewer were very slow when things got big. I optimized this a lot and now I’m pretty proud of how snappy it is.
I’m not saying this as a plug (this is mostly a passion project not a big business) but to say that it’s possible to make a snappy GitHub PR UI using a frontend framework on top of GitHub’s own APIs. You just have to care. It’s not clear that they care.
At least as reference for rewrite developers to remind what that should strive to outperform.