"GitHub" Is Starting to Feel Like Legacy Software

The thing that's really legacy in GitHub is the code review flow, which is likely one of the surface areas that corporate customers use the most.

Actions and Codespaces have been huge and transformative, so it's disappointing that core functionality like code reviews hasn't seen the same level of improvement.

Basic features that Phabricator had nearly a decade ago are still missing: - highlighting copied/moved code blocks - gutter indicators for code coverage - stacked diffs - not collapsing large changes by default (what a ridiculous default! "A lot of code has changed here, meaning it's likely bugs may be here - I'll hide that for you to make your review easier!")

And I don't recall how well Phabricator supported it, but handling rebases sanely by carrying over comments and showing diffs from prior PR versions across rebases would be amazing. The number of times I have to re-review an entire PR in GitHub because it can't show what changed since the last review if the author rebases their branch...

It's really nice to have reliable tools that you can learn once and continue using a decade to free your mind up to master other parts of the job. (like the CSS in JS flavor of the week)

Same thing seems to apply to Visual Studio Code. Sure they have a big changelog, but the actual experience of using it feels very much like when it first released.

GitHub’s most important product at this point is probably the API. It’s incredibly comprehensive so it’s easy for tools to augment or replace pretty much any part of the experience.

So many teams with private repos only use GitHub for the basics (version control, access management) and then use third party compatible tools for the rest. Linear for issues, Buildkite for CI, Graphite for code review, etc.

The API allowed me to build CodeApprove (codeapprove.com), which is the code review interface I always wanted GitHub to have. And teams that share my preferences can use it a la carte without losing the rock solid foundation of GitHub.

I know it’s not great that we’re all locked into this platform that is owned by a megacorp that hasn’t always been friendly, but it’s at least a great platform.

The complaint in the article is legit, and it sounds completely plausible that is it due to re-write to React, as avoiding rendering of off-screen content is fairly standard practice in React, as a performance optimization.

But that really is about the management of the re-write, not the tech. Someone at github decided to not render off-screen content. That breaks expectations compared to how it worked before, and that is why it feels like the app is going downhill.

The bigger point being that if anyone is doing a re-write, and trying to match the existing UX... that needs to be a deeper match than just getting the pixels in the right place.

I've heard this opinion echoed a lot (esp on Twitter), but I don't agree with it at all. I think Github is still an amazing piece of software, and Microsoft has invested in it more than almost any recent acquisition from any parent company.

This feels like a quite dramatic framing for a bug that popped up in a very complex piece of software.

I remember when Jira introduced this exact same text rendering regression. The Kanban board we used at work was hardly packed, it usually less than two dozen tickets on it. I hit ctrl+f to jump to the ticket number I new I wanted and... nothing. The browser couldn't find it! Turned out that the ticket was slightly below the view port and rendering 20 tickets at once is apparently too much for a modern ticketing web app.

The amount of regressions in modern frameworks can be staggering at times. Personally I would be embarrassed to work on a well resourced project that could handle such basic tasks, but I'm sure the redesign that introduced this regression was done with all sorts of buzzy frameworks and patterns that look great on a resume.

Before the Microsoft take-over GitHub was fairly stagnant for quite a few years. Remember not being able to meaningfully copy code because it would also copy the line numbers? Kind of ridiculous that took such a long time to fix. But for the last few years ... yeah, I feel it's just getting slowly more annoying. I sometimes genuinely wonder if the people working on GitHub actually use it themselves.

I've tried reporting some really obvious and annoying bugs to GitHub, and they even never got fixed, took months to get fixed, or got fixed and then broke again a while later. I stopped bothering.

GitLab is still tons worse, so there's that.

As for React, unfortunately there is a contingent of frontend developers who seem to think that everything must be React, that React is the only possible answer, and everyone not using React is a decrepit developer and probably a decrepit human being and quite possibly a registered nonce, and will generally just forever bang on about React until the entire world has converted to React. Your frontend will be assimilated.

React is not the only tech where this is a problem, but it is probably among the more frustrating because as a user I don't really care what language or database you use as I typically don't really interface with it, but I do interface directly with your frontend.

GitHub is moving to react for the web UI? Sad, Rails offers ways to deliver async updating views with websockets ala Elixir Liveview. I’ve pretty much abandoned Vue after discovering how much easier it is to maintain by keeping as much as possible in Rails. Not just myself but the whole team works quicker that way, backend people often know enough frontend but might not know the depths of Vue/React so it creates delays by distributing simple tasks. Plus the whole mass duplication of logic (permissions, models, etc).

You’d need to some pretty serious “desktop style” (hate that phrase) UI complexity to demand React and I’m not fully seeing where GitHub needs that.

Maybe they want to make GitHub like VSCode in the browser?

Please don't say this!

They'll go and 'modernize' it, making it some nasty 10x slower and more bloated webUI, and move all the buttons and URLs about just for the sake of it.

I find GitHub to broadly be ok.

One exception I have is for code reviews, arguably its most important usecase. Once there’s a little back and forth going on and a few rounds of things being fixed it becomes really hard to find a list of the comments. Maybe I’m just missing it somewhere but spread in the conversation tab it’s impossible to find things.

I’ve resorted to a couple of scripts that pull all the threads down into a file I can open in vim. Then I have a shortcut for jumping to the corresponding location in the code. Works well, but seems really unnecessary.

> and find a good local blame tool that works as well as the GitHub web interface used to

I don't exactly what you want, but if you want a better look of git blame, git show, git diff and so on I suggest delta. Delta formats the output of those git commands so you can see their output in prettier way. You can also use it as a human-readable diff replacement. More info: https://dandavison.github.io/delta/

However, even though git blame (and its graphical interfaces) is a quick and easy tool, it has some problems, and Git has better tools for code archaeology. Check this for more info: https://news.ycombinator.com/item?id=39877637

As someone who used GitHub for years (2009-2014), got acquired into a big tech company for 8 years, so I didn't get to use it much, and then got to go back to a startup that used it again, it feels like a totally different product. It's a starkly different offering from that perspective.

GitHub Actions are a major part of that. Codespaces, a solution for Mac CI, that you automate so much, store secrets, drive not CI but CD straight from GitHub now, etc. It's evolved a ton. Then you have the other things they are doing as company with copilot and vscode (and formerly atom).

Sure, code search is only moderately better, and maybe some of the core git features aren't getting as much razzle-dazzle in the UI, but it's evolved a ton.

Disabling JavaScripts does not always work for all files, for some reason; I don't know why. Some files can be displayed even though JavaScripts are disabled, but some don't work. Some files will only partially work if JavaScripts are disabled.

However, even if it doesn't work, the server will send the JSON as a part of the HTML file, which contains all of the relevant data, so I wrote my own script which is much shorter and much faster than those in GitHub, which also avoids needing extra requests to download the scripts.

Also, it does support the git protocol so that can still be used, and there is also the API and fortunately it has good documentation, and that does work without JavaScripts (documentation should always be made to work without JavaScripts; if your web site has documentation and does not work without JavaScripts, please correct that, even if there are valid reasons why the other files might not work without JavaScripts (which is uncommon, because usually it is for no good reason)).

Still, it isn't very good that they have to do that; they should allow to design to work without such a mess. (How they describe in this article, it does have the problems described there and more; this is because of the messy of WWW, but they could avoid using much of the newer stuff, and make it more compatible and improve accessibility and avoid many problems where they need to add considerations that should not even be necessary to consider if it was designed properly (since then the client would be able to handle it automatically according to the user preferences, without needing to be told by the server).

This feeling, plus their lack of stacking support, is what motivated Tomas, Merrill, and me to hack on graphite.dev for years

I had a moment recently where I was trying to understand "why developers would create such an interface" in an application I was using when I realized I was looking at, basically, a "React-type interface" in a place where that doesn't fit, and the "why" is perhaps that this is the kind of thing younger developers are used to seeing/implementing, so they probably don't even recognize when it's a bad approach.

> “Feel Like Legacy Software”

Is a bit ironic to state given their blog design is reminiscent of OS X ‘brushed metal’ theme from 24-years ago

https://en.m.wikipedia.org/wiki/Aqua_(user_interface)#/media...

I am increasingly anti-react. It's infuriating that on a daily basis, multiple times per day all over the place, I'm dealing with UI lag problems. I'm tired of buttons moving between the time my finger starts to move and the time when the mouse click registers, or the finger tap on a touchscreen registers, because one module loaded ten seconds after all the rest.

GitHub's notifications are the worst. Completely useless; nay, infuriating. That's the first thing they should improve IMO.

Whilst I do get the _motivation_ behind collapsing large files in diffs, because you want to keep the number of DOM elements low, come on... you really _cannot_ hide the lion's share of changes in the PR and get away with it. At least make the collapsed files stand out more so you don't actually miss them when reviewing. Or, I guess you didn't want me to expand them, or you did all that collapsing effort for no reason. So what was the point again?

Org gists were proposed like 10 years ago, but still not in place. Seems straight forward enough...

Yeah, im not a big fun of GitHub (especially after Microsoft aquasition), but I also hate that stupid 'we need to grow', 'we need to expand' attitude. Sometimes, tool is done and there is really not much you can improve upon. Especially from UI stand point of view. If you start to force that improvement, usually you end up with over-engineered stuff that starts to be pain to use.

Not always legacy stuff means it bad or should be avoided. Actually, most of the time its kinda other way around. It means its stable and just helps you get the job done. The balance between legacy and progress is not that obvious imo.

It actually sounds like a bug. In the apps I'm writing, when someone reports something like that, I consider it a "bug," and try to address it.

> I’ve seen a lot of tools hit a plateau.

I consider that the ideal state, for development platforms. Constant tweaking can cause really big problems (which actually sounds like what happened, here). I have had Xcode fart on me, in a big way.

A while back I started on an experiment to build a local-first GitHub client: https://github.com/tinyplex/tinyhub

It certainly _seems_ like the GitHub interface should feel more like an 'app', and less a 'site'. Or just me?

GitHub is slowly prioritizing social features over developer tools and experience. The number of devs concerned with GitHub Stars these days is a little concerning. I feel like at least once a week, I see a post on HN asking for ways to boost their stars on their GitHub repos.

I'm watching one important QOL feature request on the desktop app that has gone unaddressed for 6 years. They just don't care about their user's experience, just their own priorities and roadmap. It's like an abusive relationship.

Same issue (lazy loading) exists with Gitlab also. And also MR pages are so overloaded (with scripts?) so it loads and renders forever for any seriously large (yes, it happens with a large codebase) changeset.

I feel like the post has a narrow focus. Github is solving a quite heterogeneous problem for a diverse audience. People use Github and Git in completely different ways; so they have a spacebar heating issue. Their blame view, which half the post is about, I've rarely ever used. Likewise, some teams rebase during code review, others handle review outside, etc etc.

As for the Ctrl+F issue, I could see that rendering giant files with syntax highlighting can tank performance on older computers, and that they're trying to fix it for people who use Github (on web - remember), thinking that if you need full greppability, you might clone the repo locally.

I don't know, maybe Github is screwing everything up behind the scenes, but this post doesn't make a compelling argument in my view.

I haven't seen an octopress site in a hot minute. I miss octopress and the dev culture of writing that came with it, personal website. Shared template based on max writing speed and efficiency.

Does anyone know of any client-side blame front-ends for Git? I used to use the one from Git Extensions, but since an indeterminate amount of time ago, it just stopped working for me.

> The problem wasn’t that the line I wanted wasn’t on the page—it’s that the whole document wasn’t being rendered at once, so my browser’s builtin search bar just couldn’t find it.

Ctrl/Cmd-F is intercepted on blame/code pages and opens a custom find UI, which honestly seems fine to me. Browser find-in-page isn't meant for code search and it's pretty slow.

Maybe GitHub is switching to React (I don't know anything about that), but React doesn't mandate, or even natively support, culling offscreen content, so I'm not sure what the connection is there.

For a blame view, OpenGrok has an "Annotate" feature.

Gitlab has been much faster than Github for a while now.

I wish all software felt like legacy software.

I honestly cannot tell whether this blog is trolling, but the comments here suggest they are not.

Am I the only one who is satisfied running `git blame` in my terminal, using `less` as the pager and searching by pressing `/`?

Well, it is. It's a big ass antique rails app that tries to be fast with turbolinks.