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!
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.
Wow, that post is amazing. They observed that their page worked poorly because it had a lot of DOM nodes, and they don’t even discuss the idea of trying to make a usable page with fewer DOM nodes. Instead they add all manner of complexity and more nodes (!) to make it sort of work.
A web browser can render and search a boring pure-HTML syntax-highlighted source file just fine.
There was a video recently talking about this with a good visualization [0]
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.
Yes this shift to React is really annoying. Github also stopped working on older browsers.
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.
Don't forget many of those very junior developers they've unleashed on the front end is GitHub Copilot. Vibe coding is the new GitHub mandate, because they are serious about dogfooding.
I’m glad to see my feelings validated. I’m always grumpy about some good, functional software being made worse because there is a big engineering org who has to work on something so they change things and it results in degradation of the software.
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.
It's also getting a lot flakier. Around October or November of last year I realized that every week I see another bit of SPA jankiness. I lose my scroll position because some component has appeared or disappeared above view. The issues list shows hours-old state and does not refresh. A button doesn't work. A page loads but everything below the header is unstyled. I expand the build details but it collapses closed every time a stage finishes. A filename header appears twice. New comments don't appear. On and on.
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.
It feels very similar to Facebook UIs and everything under FB for Business (managing ads, Instagram comments, etc). Definitely because of React and the amount of client side rendering logic in general.
Which is crazy given how little interactivity and DOM state a site like GitHub actually needs to manage.
it felt like DNS was broken at some points because the page just wouldn't load, and sometimes just the navigation bar would load, but no content -- is this what you're talking about ?
Using the symbol explorer (or whatever it’s called) on files is nice for following definitions through files, but it makes the browser back button completely non-functional. Often the URL will actually change to the previous history state, but the page content never changes. Trying to then reload with the changed URL also doesn’t work for whatever reason.
It would be a really great feature if it worked correctly.
Reminds me of a discussion that Casey Muratori and Robert Martin had over clean code and it's impact on performance... but not because of the subject matter. They were using GitHub as a medium for their discussion, and they ran into some serious lag when typing paragraphs into just the hundreds of characters (ctrl+f emoji, ~1/4 of the way through):
Obviously if you use any kind of javascript on such website things go to hell.
Git solutions are Forgejo are running circles around gitlab and github, it renders everything insanely fast.
Disappointing devs still try to justify javascript on large sites like git.
GitHub, Facebook, Reddit, Instagram (on the web)...
All these major websites are becoming incredibly hard to use. My intuition would be "SPA crap" but I'm pretty sure you can make great and snappy SPAs. What am I missing?
If you just need a place to store your code, self-hosted Gitea is very easy.
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".
As an interesting example of the opposite UI experience, this video goes into why the McMaster-Carr website is so incredibly snappy to use: https://youtu.be/-Ln-8QM8KhQ.
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.
wow, every web ui is going to shit after a decade of cargo culting SPAs and shiny completely unnecessary frameworks! no one could have possibly saw this coming.
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.
54 comments
[ 4.4 ms ] story [ 71.6 ms ] threadIt's basically impossible to view diffs now because they often fail to load, render correctly, or just are incredibly slow.
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.
A web browser can render and search a boring pure-HTML syntax-highlighted source file just fine.
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-mo...
[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...
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.
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.
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.
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/c...
Disappointing devs still try to justify javascript on large sites like git.
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.
- https://gitpatch.com/gitpatch/git-demo
- https://github.com/git/git
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.