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.
Why is GitHub UI getting slower?
51–60 of 123 posts
Re: Why is GitHub UI getting slower?
#52wow, 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.
Re: Why is GitHub UI getting slower?
#53Because Microsoft bought them.
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.
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.
Re: Why is GitHub UI getting slower?
#54Githubs 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.
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.
Re: Why is GitHub UI getting slower?
#55I'm building a new Git hosting service, focused on performance and using HTMX. For example, compare page load time:
Re: Why is GitHub UI getting slower?
#56I suffer it and that’s why I’m building 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.
Re: Why is GitHub UI getting slower?
#57Earlier quoted context omitted.
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.
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 consist…
> 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):
Re: Why is GitHub UI getting slower?
#58Earlier quoted context omitted.
Pretty sure it used to be more server rendered?
Most of it still is server rendered.
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.
Re: Why is GitHub UI getting slower?
#59i've noticed viewing diffs to be a painpoint, doesn't load the entire thing.
Re: Why is GitHub UI getting slower?
#60Githubs 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.
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.