| ▲ | xPaw 5 days ago |
| Githubs performance has been rapidly degrading ever since they started rewriting everything in React. It's basically impossible to view diffs now because they often fail to load, render correctly, or just are incredibly slow. |
|
| ▲ | srhtftw 5 days ago | parent | next [-] |
| 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. |
| |
| ▲ | sexy_seedbox 4 days ago | parent [-] | | Pretty much all of Microsoft — Admin Center, Entra, Defender, etc, they all load slowly and then show you more "silver shimmers effects". |
|
|
| ▲ | arp242 5 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | mintplant 5 days ago | parent [-] | | > 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. | | |
| ▲ | B56b 4 days ago | parent [-] | | It breaks so often in SPAs. Turns out that making the client-side code responsible for routing leads to a ton of fragility. |
|
|
|
| ▲ | amluto 5 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | hedgehog 5 days ago | parent | prev | next [-] |
| I don't know any of the background but the diff viewer is near unusable past around 5k lines of diff on my M1 Mac. |
| |
| ▲ | whalesalad 5 days ago | parent [-] | | That’s your first problem right there. A diff of that magnitude is too large periodt. | | |
| ▲ | DanOpcode 5 days ago | parent [-] | | After all years of advancement in computing, and in the year 2025 it's not possible to show a 5000 lines diff anymore. | | |
| ▲ | whalesalad 5 days ago | parent [-] | | I just mean that if you are reviewing over 5k lines of code, it suggests your PR is too big and should have been broken up into smaller changes. | | |
| ▲ | homebrewer 5 days ago | parent | next [-] | | It's not always code. I sometimes review things like translations that are often done in bulk (thousands of strings in a single batch). There's not much structure to it, it's not like reviewing some weird multi threaded super complicated algorithm, you just need to skim it quickly and make sure that the structure is not broken, and there are no screaming text blocks or unnecessary profanities. Anyway, it did work properly, now it doesn't. The response shouldn't be "you're holding it wrong". | |
| ▲ | thfuran 5 days ago | parent | prev | next [-] | | What about when you're renaming a widely used type in a large codebase or any of the many other things that it makes no sense to attempt to break up into small changes? I completely understand a preference for well-structured smaller changes, but the "large change = doing it wrong" zealotry is misguided. | |
| ▲ | saagarjha 5 days ago | parent | prev | next [-] | | I'm not always reviewing code. Sometimes I'm checking a diff between two versions of the code, which might contain multiple commits. | |
| ▲ | amluto 4 days ago | parent | prev [-] | | If someone is adding a 5k-line file, I would usually rather review it as a single chunk. And yes, sometimes a 5k-line file is entirely justified. |
|
|
|
|
|
| ▲ | Delgan 5 days ago | parent | prev | next [-] |
| I was baffled by the technical blog post they published on this subject, in 2023: https://github.blog/engineering/architecture-optimization/cr... 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 5 days ago | parent | next [-] | | 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. | |
| ▲ | amluto 4 days ago | parent | prev [-] | | 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. |
|
|
| ▲ | CharlieDigital 5 days ago | parent | prev | next [-] |
| 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. [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 5 days ago | parent | next [-] | | 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. | | |
| ▲ | CharlieDigital 4 days ago | parent [-] | | It's not because of the YT video; it's that the YT video provides a good walkthrough. I've been working with JS since the late 90's and have seen various front-end stacks come and go so to me, it is pretty obvious that React has this inverted nature and it is this inverted nature that is the root cause of why it's a very technical endeavor to get it to perform well at scale as it requires the engineer to think carefully about memoization and state placement -- something that doesn't happen in vanilla JS and early frameworks like KnockoutJS. |
| |
| ▲ | zahlman 5 days ago | parent | prev [-] | | 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!) | | |
| ▲ | CharlieDigital 5 days ago | parent [-] | | All modern FE frameworks are effectively observer patterns, it's that there are two camps on how those changes in the state are propagated. 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. |
|
|
|
| ▲ | jmrm 4 days ago | parent | prev | next [-] |
| Even tech influencers who love React, like Theo Browne, has heavily criticise how bad is made GitHub in that regard. 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. |
|
| ▲ | chistev 5 days ago | parent | prev | next [-] |
| Were they using vanilla js? That's impressive if yes. |
| |
| ▲ | simonw 5 days ago | parent | next [-] | | 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. | | |
| ▲ | spankalee 5 days ago | parent [-] | | I think it was two things: 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. | | |
| ▲ | jauntywundrkind 5 days ago | parent | next [-] | | > 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. 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): https://open-ui.org/components/invokers.explainer/ | |
| ▲ | WorldMaker 5 days ago | parent | prev [-] | | > 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. 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. |
|
| |
| ▲ | johnmaguire 5 days ago | parent | prev | next [-] | | 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. [0] https://web.archive.org/web/20100115102310/http://github.com... (interestingly, elan/plex shows up as a recently updated repo!) | |
| ▲ | spankalee 5 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | mdhb 5 days ago | parent | next [-] | | Also as a part of their bullshit React rewrite in addition to making everything much much slower they also managed to break basic functionality like the back and forth buttons on Safari that only got fixed quite recently but for a good 9-12 month period it was impossible to use on iOS. Genuinely whoever was a part of pushing this rewrite should have been fired. | | |
| ▲ | jdlshore 4 days ago | parent [-] | | I know you’re just expressing your frustration, but the “the person who did this should be fired” meme you’re propagating is pretty toxic. Decisions like this are never the work of one person, and even when they are, any problems you’re perceiving were traded off against other problems you’re not perceiving. And even if it was an unadulterated mistake, it’s just that… a mistake. Should you get fired for the mistakes you make? 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. |
| |
| ▲ | koakuma-chan 5 days ago | parent | prev | next [-] | | Just use that thing that renders React 1000x faster, million JS or something | | | |
| ▲ | 5 days ago | parent | prev [-] | | [deleted] |
| |
| ▲ | LoganDark 5 days ago | parent | prev | next [-] | | Pretty sure it used to be more server rendered? | | |
| ▲ | princevegeta89 5 days ago | parent [-] | | Most of it still is server rendered. | | |
| ▲ | arp242 5 days ago | parent [-] | | I believe most stuff gets loaded via a JSON API now, and HTML rendered in JS via Rect. Maybe even all of it? 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. |
|
| |
| ▲ | 5 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | bapak 5 days ago | parent | prev [-] | | Most of the UI is React now, especially the most commonly used areas. | | |
| ▲ | Imustaskforhelp 5 days ago | parent [-] | | The parent comment actually asks what they were doing before using React...
No worries, you may have misunderstood them and that's okay! | | |
|
|
|
| ▲ | OptionOfT 5 days ago | parent | prev [-] |
| I wonder if it's React. The GitHub app takes between 3 and 4 seconds to refresh the notifications, and I only have about 20 in my list. |
