7 ms·

Why is GitHub UI getting slower?

235 points by lr0 1y ago

fridder 1y ago
Incredibly well timed given today's outage
elmwoodfire3 1y ago
[dead]
throwaway290 1y 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!
xPaw 1y 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.
- chistev 1y ago
  Were they using vanilla js? That's impressive if yes.
  - bapak 1y ago
    Most of the UI is React now, especially the most commonly used areas.
    - Imustaskforhelp 1y ago
      The parent comment actually asks what they were doing before using React... No worries, you may have misunderstood them and that's okay!
      - deleted 1y ago
        [deleted]
  - LoganDark 1y ago
    Pretty sure it used to be more server rendered?
    - princevegeta89 1y ago
      Most of it still is server rendered.
      - arp242 1y ago
        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.
  - radlad 1y ago
    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/ https://web.archive.org/web/20100115102310/http://github.com... (interestingly, elan/plex shows up as a recently updated repo!)
  - spankalee 1y ago
    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.
    - koakuma-chan 1y ago
      Just use that thing that renders React 1000x faster, million JS or something
      - Dlanv 1y ago
        it has some limitations: https://old.million.dev/docs/manual-mode/block#breaking-rules-of-blocks https://old.million.dev/docs/manual-mode/block#breaking-rule... and it isn't a silver bullet on its own
    - deleted 1y ago
      [deleted]
    - mdhb 1y ago
      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 1y ago
        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.
  - simonw 1y ago
    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 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 1y ago
      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 1y ago
        > 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/ 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/ https://open-ui.org/components/invokers.explainer/
  - deleted 1y ago
    [deleted]
- amluto 1y ago
  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.
- arp242 1y ago
  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 1y ago
    > 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 1y ago
      It breaks so often in SPAs. Turns out that making the client-side code responsible for routing leads to a ton of fragility.
- Delgan 1y ago
  I was baffled by the technical blog post they published on this subject, in 2023: https://github.blog/engineering/architecture-optimization/crafting-a-better-faster-code-view/ 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 1y ago
    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 1y ago
    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.
- hedgehog 1y ago
  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 1y ago
    That’s your first problem right there. A diff of that magnitude is too large periodt.
    - DanOpcode 1y ago
      After all years of advancement in computing, and in the year 2025 it's not possible to show a 5000 lines diff anymore.
      - whalesalad 1y ago
        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.
        thfuran 1y ago
        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.
        homebrewer 1y ago
        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".
- CharlieDigital 1y ago
  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 https://youtu.be/INLq9RPAYUw [1] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react/ 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-uphill-battle-of-memoization, https://tkdodo.eu/blog/the-useless-use-callback https://tkdodo.eu/blog/the-useless-use-callback [3] https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode/#patch-flags-in-vue https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode...
  - zahlman 1y ago
    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 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!)
- OptionOfT 1y ago
  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.
- srhtftw 1y ago
  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 1y ago
    Pretty much all of Microsoft — Admin Center, Entra, Defender, etc, they all load slowly and then show you more "silver shimmers effects".
- jmrm 1y ago
  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.
bapak 1y ago
It's very obvious that they've unleashed a bunch of very junior developers on front end, it's I'm surprised that it still works. The previous AJAXed implementation had its haters, but at least it was very close to bare HTML on HTTP.
- deleted 1y ago
  [deleted]
- neomech 1y ago
  Maybe they have given most of the development over to AI?
  - AstroBen 1y ago
    The performance degradation started before the AI boom imo
    - WorldMaker 1y ago
      They seem to have been early adopters (dogfooding).
- zelphirkalt 1y ago
  Sometimes things already don't work. For example recently, I used Firefox and couldn't create an organization. It would just hang, when I clicked the green button to create it. Not sure how they could mess that one up, but when I used Chromium, it worked. It should be as simple as sending a form, but somehow they f'ed that up.
  - ctoth 1y ago
    Using ctrl+enter to open issues in a new tab... How on earth could you break this?
- WorldMaker 1y ago
  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.
gwbas1c 1y ago
> You guys developing at GitHub, you're using GitHub to develop it, right? They could be using an internal beta version so they can "eat their own dogfood" before shipping.
buyucu 1y ago
Because Microsoft bought them.
- karel-3d 1y ago
  Right after Microsoft bought them, github got better, and started implementing long-requested features. (The open letter "dear github" or whatever was that was posted right before the takeover.) This is something more recent.
  - arp242 1y ago
    Yes, remember how copying anything from the code view would also copy the line numbers? It was a relatively small CSS fix, but took years! 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.
    - karel-3d 1y ago
      Same thing about npm, btw. Both the node service and the website
  - blibble 1y ago
    big companies don't do anything fast it's a car crash in extremely slow motion
k33l0r 1y ago
Slower and broken more often, a winning combination!
- brewmarche 1y ago
  The broken navigation (back button and issues pagination and more) they introduced with the revamp is so infuriating
Starlevel004 1y ago
The code viewer is completely unusable for any file longer than a hundred lines. I have to clone it and browse locally instead. It's been like this for at least a year. Does nobody at GH actually use their own website?
Vegenoid 1y ago
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.
coffeebeqn 1y ago
Have you used any other Microsoft web services? They’re all slow and terrible
- xnorswap 1y ago
  Indeed, GitHub is still lightning fast compared to Azure Dev Ops. 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.
pushcx 1y ago
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.
- MarcelOlsz 1y ago
  My favourite github UIUX snafu is being unable to navigate back to the root repo page when I'm in some sort of complex view, or being able to go to the authors profile in less than like 5 clicks.
  - cnst 1y ago
    Re going to author's profile, I usually just give up, and go to the URL to fix the address. 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!
konstruktors 1y ago
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.
robotburrito 1y ago
Can’t they use their AI to rewrite the entire thing to be faster?
gjvc 1y ago
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 ?
nkrisc 1y ago
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.
kartoffelsaft 1y ago
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): https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md https://github.com/unclebob/cmuratori-discussion/blob/main/c...
lousken 1y ago
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.
Einenlum 1y ago
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?
- timw4mail 1y ago
  You can? I haven't seen them.
  - richwater 1y ago
    You can indeed do so, but it requires a skillset way behind new grads, bootcamps and giving up the prevailing leadership mantra of "All engineers are fungible so just throw that random team over to learn React and it'll be fine". 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.
    - krembanan 1y ago
      > Front End Engineer roles pay less than general Software Development Engineers at pretty much every FAANG 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?
  - mook 1y ago
    Google Maps from a decade ago was pretty decent. There's also GMail from around when it was new. That was all on crappier client hardware too. Note that I didn't say anything about their _current_ incarnations…
whalesalad 1y ago
it's turbolinks and rails
- mdhb 1y ago
  It WAS that (and web components) but the new fucked up version we are talking about here is React which is very literally one of the main sources of the problem.
FredPret 1y ago
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".
didip 1y ago
I still maintain that building web frontend using classical server side template + progressive enhancement in JS is superior. Too bad that everything has to be rewritten in React.
0xTJ 1y ago
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 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.
sitzkrieg 1y ago
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.
shayief 1y ago
I'm building a new Git hosting service, focused on performance and using HTMX. For example, compare page load time: - https://gitpatch.com/gitpatch/git-demo https://gitpatch.com/gitpatch/git-demo - https://github.com/git/git https://github.com/git/git
- ramon156 1y ago
  How does this compare to codeberg?
  - shayief 1y ago
    Codeberg UI appears to be pretty similar to GitHub, so it's great as GitHub alternative. It's powered by Forgejo, fork of Gitea. 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.
gimenete 1y ago
I suffer it and that’s why I’m building https://githero.app https://githero.app 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.
- deleted 1y ago
  [deleted]
- McAlpine5892 1y ago
  This looks pretty cool! Do you have a privacy policy?
  - gimenete 1y ago
    Thanks! 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.
    - bsimpson 1y ago
      FWIW, it's rendering white-on-white for me. Looks like it's missing unless you select-all.
- zahlman 1y ago
  What do you hope to offer that wouldn't be found in, say, GitLab?
  - gimenete 1y ago
    My main goal is to offer a more modern and smoother experience than GitHub, add some features on top of it like push notifications, triage of notifications, a better editing experience,… and integrate the desktop app with your local git
ayerajath 1y ago
i've noticed viewing diffs to be a painpoint, doesn't load the entire thing.
gatane 1y ago
My PC hangs as soon as any "dynamic" javascript button starts to load! I'm glad I was not the only one, finally!
muglug 1y ago
In web development, frontend product devs are not incentivized to make features fast — the general approach in companies is "ship first, optimize later". 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.
ricardobayes 1y ago
There is a whole new paradigm in UX design now: get rid of immediate page changes and loading states and instead keep the user on the same page until things load, and show it when it's ready.
- ptx 1y ago
  Modern browsers already do this by default with server-rendered pages. No JS hacks needed. (And the browser UI correctly indicates that it's in a loading state while it's loading.)
  - WorldMaker 1y ago
    Modern browsers will even animate it between server-rendered pages with View Transitions CSS now.
ramon156 1y ago
Ooh ooh I know this one! Because its Microsoft!
Jotalea 1y ago
Yes, even at the point where some items fail to render with proper style and the buttons don't work. I wish there were a GitHub frontend that used more basic HTML for it to work on older browsers and lower network speeds.
butz 1y ago
Funny to see GitHub still on the path to React, while Edge is already migrating to web components, due to performance issues related to React.
rwrrll 1y ago
Revert GitHub to any commit from 2012. Just have code, PRs, issues, fast and reliable. Rip everything else out and cast it into the sea. I would pay more for this product.
dang 1y ago
Related ongoing thread (i.e. since the OP is a few months old, I assume it was posted in connection with): GitHub pull requests were down - https://news.ycombinator.com/item?id=44799494 https://news.ycombinator.com/item?id=44799494 - Aug 2025 (113 comments)
brunojppb 1y ago
Interestingly enough, the iOS app has been working really well for me. 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.
astrolx 1y ago
It degraded so much, I remembered how the UX used to be so enjoyable. Now, a forgejo instance hosted on an old raspberry pi at home is where my projects live, and it is fast and snappy in comparison.
herbst 1y ago
The website is crashing constantly on me. I just assumed it's Microsoft doing their typical thing.
zero_bias 1y ago
I always wondered why back button in iOS is not working on github, this broken client side routing makes no sense
codeapprove 1y ago
I made a competitor to GitHubs UI for Pull Requests (codeapprove.com) 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.
cadamsdotcom 1y ago
Once a company achieves market dominance the only thing left to force a focus on users is its management.
deleted 1y ago
[deleted]
chrisbrandow 1y ago
I'm so glad someone documented this. it's been driving me crazy. I was just in a serious crunch mode for a couple of week, so all kinds of minor speed bumps in my workflow have become really evident to me. The UI transition between PR "tabs" has been one of the worst.
Self-Perfection 1y ago
We should make a cultural norm to keep old interface running when rewriting projects start. Just like https://old.reddit.com/ https://old.reddit.com/ is still chugging. At least as reference for rewrite developers to remind what that should strive to outperform.

235 points by lr0 1y ago

fridder 1y ago

Incredibly well timed given today's outage

elmwoodfire3 1y ago

[dead]

throwaway290 1y 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!

xPaw 1y 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.

chistev 1y ago
Were they using vanilla js? That's impressive if yes.
- bapak 1y ago
  Most of the UI is React now, especially the most commonly used areas.
  - Imustaskforhelp 1y ago
    The parent comment actually asks what they were doing before using React... No worries, you may have misunderstood them and that's okay!
    - deleted 1y ago
      [deleted]
- LoganDark 1y ago
  Pretty sure it used to be more server rendered?
  - princevegeta89 1y ago
    Most of it still is server rendered.
    - arp242 1y ago
      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.
- radlad 1y ago
  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/ https://web.archive.org/web/20100115102310/http://github.com... (interestingly, elan/plex shows up as a recently updated repo!)
- spankalee 1y ago
  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.
  - koakuma-chan 1y ago
    Just use that thing that renders React 1000x faster, million JS or something
    - Dlanv 1y ago
      it has some limitations: https://old.million.dev/docs/manual-mode/block#breaking-rules-of-blocks https://old.million.dev/docs/manual-mode/block#breaking-rule... and it isn't a silver bullet on its own
  - deleted 1y ago
    [deleted]
  - mdhb 1y ago
    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 1y ago
      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.
- simonw 1y ago
  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 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 1y ago
    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 1y ago
      > 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/ 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/ https://open-ui.org/components/invokers.explainer/
- deleted 1y ago
  [deleted]
amluto 1y ago
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.
arp242 1y ago
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 1y ago
  > 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 1y ago
    It breaks so often in SPAs. Turns out that making the client-side code responsible for routing leads to a ton of fragility.
Delgan 1y ago
I was baffled by the technical blog post they published on this subject, in 2023: https://github.blog/engineering/architecture-optimization/crafting-a-better-faster-code-view/ 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 1y ago
  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 1y ago
  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.
hedgehog 1y ago
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 1y ago
  That’s your first problem right there. A diff of that magnitude is too large periodt.
  - DanOpcode 1y ago
    After all years of advancement in computing, and in the year 2025 it's not possible to show a 5000 lines diff anymore.
    - whalesalad 1y ago
      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.
      - thfuran 1y ago
        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.
      - homebrewer 1y ago
        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".
CharlieDigital 1y ago
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 https://youtu.be/INLq9RPAYUw [1] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react/ 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-uphill-battle-of-memoization, https://tkdodo.eu/blog/the-useless-use-callback https://tkdodo.eu/blog/the-useless-use-callback [3] https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode/#patch-flags-in-vue https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode...
- zahlman 1y ago
  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 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!)
OptionOfT 1y ago
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.
srhtftw 1y ago
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 1y ago
  Pretty much all of Microsoft — Admin Center, Entra, Defender, etc, they all load slowly and then show you more "silver shimmers effects".
jmrm 1y ago
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.

bapak 1y ago

It's very obvious that they've unleashed a bunch of very junior developers on front end, it's I'm surprised that it still works. The previous AJAXed implementation had its haters, but at least it was very close to bare HTML on HTTP.

deleted 1y ago
[deleted]
neomech 1y ago
Maybe they have given most of the development over to AI?
- AstroBen 1y ago
  The performance degradation started before the AI boom imo
  - WorldMaker 1y ago
    They seem to have been early adopters (dogfooding).
zelphirkalt 1y ago
Sometimes things already don't work. For example recently, I used Firefox and couldn't create an organization. It would just hang, when I clicked the green button to create it. Not sure how they could mess that one up, but when I used Chromium, it worked. It should be as simple as sending a form, but somehow they f'ed that up.
- ctoth 1y ago
  Using ctrl+enter to open issues in a new tab... How on earth could you break this?
WorldMaker 1y ago
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.

gwbas1c 1y ago

> You guys developing at GitHub, you're using GitHub to develop it, right? They could be using an internal beta version so they can "eat their own dogfood" before shipping.

buyucu 1y ago

Because Microsoft bought them.

karel-3d 1y ago
Right after Microsoft bought them, github got better, and started implementing long-requested features. (The open letter "dear github" or whatever was that was posted right before the takeover.) This is something more recent.
- arp242 1y ago
  Yes, remember how copying anything from the code view would also copy the line numbers? It was a relatively small CSS fix, but took years! 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.
  - karel-3d 1y ago
    Same thing about npm, btw. Both the node service and the website
- blibble 1y ago
  big companies don't do anything fast it's a car crash in extremely slow motion

k33l0r 1y ago

Slower and broken more often, a winning combination!

brewmarche 1y ago
The broken navigation (back button and issues pagination and more) they introduced with the revamp is so infuriating

Starlevel004 1y ago

The code viewer is completely unusable for any file longer than a hundred lines. I have to clone it and browse locally instead. It's been like this for at least a year. Does nobody at GH actually use their own website?

Vegenoid 1y ago

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.

coffeebeqn 1y ago

Have you used any other Microsoft web services? They’re all slow and terrible

xnorswap 1y ago
Indeed, GitHub is still lightning fast compared to Azure Dev Ops. 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.

pushcx 1y ago

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.

MarcelOlsz 1y ago
My favourite github UIUX snafu is being unable to navigate back to the root repo page when I'm in some sort of complex view, or being able to go to the authors profile in less than like 5 clicks.
- cnst 1y ago
  Re going to author's profile, I usually just give up, and go to the URL to fix the address. 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!

konstruktors 1y ago

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.

robotburrito 1y ago

Can’t they use their AI to rewrite the entire thing to be faster?

gjvc 1y ago

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 ?

nkrisc 1y ago

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.

kartoffelsaft 1y ago

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): https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md https://github.com/unclebob/cmuratori-discussion/blob/main/c...

lousken 1y ago

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.

Einenlum 1y ago

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?

timw4mail 1y ago
You can? I haven't seen them.
- richwater 1y ago
  You can indeed do so, but it requires a skillset way behind new grads, bootcamps and giving up the prevailing leadership mantra of "All engineers are fungible so just throw that random team over to learn React and it'll be fine". 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.
  - krembanan 1y ago
    > Front End Engineer roles pay less than general Software Development Engineers at pretty much every FAANG 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?
- mook 1y ago
  Google Maps from a decade ago was pretty decent. There's also GMail from around when it was new. That was all on crappier client hardware too. Note that I didn't say anything about their _current_ incarnations…

whalesalad 1y ago

it's turbolinks and rails

mdhb 1y ago
It WAS that (and web components) but the new fucked up version we are talking about here is React which is very literally one of the main sources of the problem.

FredPret 1y ago

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

didip 1y ago

I still maintain that building web frontend using classical server side template + progressive enhancement in JS is superior. Too bad that everything has to be rewritten in React.

0xTJ 1y ago

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

sitzkrieg 1y ago

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.

shayief 1y ago

I'm building a new Git hosting service, focused on performance and using HTMX. For example, compare page load time: - https://gitpatch.com/gitpatch/git-demo https://gitpatch.com/gitpatch/git-demo - https://github.com/git/git https://github.com/git/git

ramon156 1y ago
How does this compare to codeberg?
- shayief 1y ago
  Codeberg UI appears to be pretty similar to GitHub, so it's great as GitHub alternative. It's powered by Forgejo, fork of Gitea. 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.

gimenete 1y ago

I suffer it and that’s why I’m building https://githero.app https://githero.app 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.

deleted 1y ago
[deleted]
McAlpine5892 1y ago
This looks pretty cool! Do you have a privacy policy?
- gimenete 1y ago
  Thanks! 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.
  - bsimpson 1y ago
    FWIW, it's rendering white-on-white for me. Looks like it's missing unless you select-all.
zahlman 1y ago
What do you hope to offer that wouldn't be found in, say, GitLab?
- gimenete 1y ago
  My main goal is to offer a more modern and smoother experience than GitHub, add some features on top of it like push notifications, triage of notifications, a better editing experience,… and integrate the desktop app with your local git

ayerajath 1y ago

i've noticed viewing diffs to be a painpoint, doesn't load the entire thing.

gatane 1y ago

My PC hangs as soon as any "dynamic" javascript button starts to load! I'm glad I was not the only one, finally!

muglug 1y ago

In web development, frontend product devs are not incentivized to make features fast — the general approach in companies is "ship first, optimize later". 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.

ricardobayes 1y ago

There is a whole new paradigm in UX design now: get rid of immediate page changes and loading states and instead keep the user on the same page until things load, and show it when it's ready.

ptx 1y ago
Modern browsers already do this by default with server-rendered pages. No JS hacks needed. (And the browser UI correctly indicates that it's in a loading state while it's loading.)
- WorldMaker 1y ago
  Modern browsers will even animate it between server-rendered pages with View Transitions CSS now.

ramon156 1y ago

Ooh ooh I know this one! Because its Microsoft!

Jotalea 1y ago

Yes, even at the point where some items fail to render with proper style and the buttons don't work. I wish there were a GitHub frontend that used more basic HTML for it to work on older browsers and lower network speeds.

butz 1y ago

Funny to see GitHub still on the path to React, while Edge is already migrating to web components, due to performance issues related to React.

rwrrll 1y ago

Revert GitHub to any commit from 2012. Just have code, PRs, issues, fast and reliable. Rip everything else out and cast it into the sea. I would pay more for this product.

dang 1y ago

Related ongoing thread (i.e. since the OP is a few months old, I assume it was posted in connection with): GitHub pull requests were down - https://news.ycombinator.com/item?id=44799494 https://news.ycombinator.com/item?id=44799494 - Aug 2025 (113 comments)

brunojppb 1y ago

Interestingly enough, the iOS app has been working really well for me. 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.

astrolx 1y ago

It degraded so much, I remembered how the UX used to be so enjoyable. Now, a forgejo instance hosted on an old raspberry pi at home is where my projects live, and it is fast and snappy in comparison.

herbst 1y ago

The website is crashing constantly on me. I just assumed it's Microsoft doing their typical thing.

zero_bias 1y ago

I always wondered why back button in iOS is not working on github, this broken client side routing makes no sense

codeapprove 1y ago

I made a competitor to GitHubs UI for Pull Requests (codeapprove.com) 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.

cadamsdotcom 1y ago

Once a company achieves market dominance the only thing left to force a focus on users is its management.

deleted 1y ago

[deleted]

chrisbrandow 1y ago

I'm so glad someone documented this. it's been driving me crazy. I was just in a serious crunch mode for a couple of week, so all kinds of minor speed bumps in my workflow have become really evident to me. The UI transition between PR "tabs" has been one of the worst.

Self-Perfection 1y ago

We should make a cultural norm to keep old interface running when rewriting projects start. Just like https://old.reddit.com/ https://old.reddit.com/ is still chugging. At least as reference for rewrite developers to remind what that should strive to outperform.