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.
Everything has been getting worse since the React rewrite(s). Everything is just so much more slower and janky. And things like the "back button" keep acting weird (I reported this several times, after a long delay they fixed it several times, and it just keeps breaking a few weeks later – I've given up).
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.
> And things like the "back button" keep acting weird
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.
Trying to find a string in github actions logs is just impossible. Not to mention that even opening large logs takes many seconds of animated scrolling to get to the end.
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.
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.
I particularly appreciate when the diff is the addition of a new file and it still takes forever to compute a diff or whatever it’s doing behind the scenes.
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.
Yeah, so you can't blame every performance issue you come across on a single topic, just because you've seen a YouTube video.
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.
Interesting to contrast that with the assessment of React, qua critique of the Observer pattern in Brandon Rhodes' 2022 design patterns talk: https://www.youtube.com/watch?v=pGq7Cr2ekVM?t=28m45s . (Notably, later in the talk when he describes the Mediator pattern with a GUI-motivated example, he preempts by saying "I know I just told you to use React"... but then the description ends up sounding to me very much as if React is an implementation of the Mediator pattern!)
They used mostly vanilla JS for over a decade. They were early proponents of a technique they called PJAX which is actually pretty similar to how HTMX works: https://github.com/defunkt/jquery-pjax
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.
Github was originally written in Ruby on Rails back in 2008. React was released to the public in 2013 (though it was in use at Facebook prior to that.)
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.
They were, and still very much are, using web components. But they hired a team to do experiments to imagine the future of GitHub UI, and that team built everything in React. Now that team's work is being ported to the production UI.
srhtftw|6 months ago
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.
sexy_seedbox|6 months ago
arp242|6 months ago
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.
mintplant|6 months ago
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.
Delgan|6 months ago
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.
progbits|6 months ago
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.
amluto|6 months ago
A web browser can render and search a boring pure-HTML syntax-highlighted source file just fine.
hedgehog|6 months ago
whalesalad|6 months ago
amluto|6 months ago
CharlieDigital|6 months ago
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...
SebastianKra|6 months ago
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.
zahlman|6 months ago
chistev|6 months ago
simonw|6 months ago
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.
johnmaguire|6 months ago
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!)
spankalee|6 months ago
LoganDark|6 months ago
unknown|6 months ago
[deleted]
bapak|6 months ago
jmrm|6 months ago
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.
OptionOfT|6 months ago