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...
To be fair, they did improve several things in the PR flow over the last decade but there's definitely a lot more that could be done. I just hope they keep their API team well-resourced so that code review tools like Graphite and Reviewable can keep working! (Disclaimer: I'm the founder of Reviewable.)
This is 100% true. For some reason GitHub has put very little love into code review even though the Pull Request is probably their most important flow.
The good news is that many people have built better code review interfaces on top of GitHub. My favorites:
- CodeApprove (I created it, so yeah I like it)
- Graphite
- Reviewable
- GitContext
Check them out! You’d be surprised how much better they are and how quick they are to set up.
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.
> 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.
I strongly agree, and it's weird how much hostility I encounter from folks who think the opposite. There are an endless amount of interesting and/or useful things to learn in this industry; spending time relearning how to do a mundane task in an app I've been using for a decade is a waste.
> There are an endless amount of interesting and/or useful things to learn in this industry; spending time relearning how to do a mundane task in an app I've been using for a decade is a waste.
It's not just "in this industry," the problem is a societal one. It just goes to show you how unwise some people are. They like to "learn new things," so proceed to relearn the same thing over and over. They got brainwashed by the "new is better" meme.
That's what the the post's author wants, but apparently Microsoft is breaking github instead.
I am sure Github will be around in the decade, but I am not sure at all it will still be everyone's default location to host source code. Which is a pity.
A pity? Uh, no. Please, move the network effects to a platform not owned by Microsoft and their shitty AI venture so my code can follow suit, for the love of god, HURRY!
It has great extensions, lets you work on remote machines as if they were local, and supports language servers, notebook interfaces, and all manners of code intelligence.
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.
Agreed that their API is the most important thing, but IMHO they're not doing a particularly great job of it. You've got two separate API systems (REST and GraphQL) that overlap but with neither a superset of the other, two separate ID systems, no help in handling the wide range of incompatible API versions used by old GHE instances in the field, OAuth apps vs Apps that have different constraints on the APIs they're allowed to call and with no clear migration path between them, important bits of functionality used by their own UI that aren't available through the API at all, a convoluted API quota system, etc.
Frankly, a lot of it feels like they were trying to deprecate and replace an older system with the shiny new thing, then realized halfway through that they couldn't and now we're stuck with two somewhat incompatible ones for the foreseeable future. They could really use a strong tech lead on this.
It feels this way with PATs as well, with legacy PATs still necessary for most of the things I use them for, despite being pushed into the newer ones. And the documentation is terrible. I had the exact same thought, the PAT transition feels like an unfinished feature as does the API transition.
For me the API transition is even more bizarre since it’s almost trivial to wrap REST calls with GraphQL.
What it feels like to me is a mounting level of serious technical debt which isn’t being addressed, and if that’s not a sign of trouble in a product like GitHub, I don’t know what is.
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.
It's not a bug, though. Like many web sites these days, they don't load the entire page upon navigation as a deliberate design choice to save bandwidth and resources of the client browser.
I've been bitten by this one before as well. Looking at the files tab of a pull request, I hit ctrl-f and started typing the name of a file I knew was part of the PR, and...nothing. No hits. Couldn't find it.
It wasn't until I scrolled down a little bit that the JS on the page loaded more of the diff and THEN the file I was looking for appeared in the list and could then be clicked to scroll to that file.
This kind of lazy loading saves system resources for both client and server, but reduces usability.
> as a deliberate design choice to save bandwidth and resources of the client browser.
The complete source file is likely a tiny fraction of the size of the React gunk to show it.
It's more they're trying to limit DOM size than download size, with a virtual view. And, unfortunately, HTML virtual views break things like find-in-page.
This pattern is so frustrating - especially when they capture the hotkey for find in page but not until js has fully loaded. Makes me wonder if exposing the browser find events to the page could help - handle the find event by ensuring the whole dom is loaded and searchable.
I feel "Github is still an amazing piece of software" and "GitHub has annoying bugs it really shouldn't have" are not really conflicting opinions; they can both be true at the same time.
I use GitHub because it's still the best option, by quite some margin.[1] But I also think it has stupid bugs (that sometimes take ages to fix), some misdesigns, and at times complete misfeatures.
For example if you have a light colour scheme the GitHub actions log is shown as fairly low-contrast dark. This is quite unreadable for me; there's a reason I use the light theme. So I need to open the 'raw log' and check it from there. Is this doable? Yes. Do I absolutely hate having to use GitHub Actions because it's just such an annoying workflow? Also yes.
GitHub discussions is borderline useless. Try commenting on a larger thread; you'll struggle finding your own comment and seeing if anyone replied. Making a conversation UI that's more confusing and worse than Twitter is quite the achievement, but GitHub pulled it off.
Some of this is just mystifying; these are not new features, and pretty low-hanging fruit. Just like how the back button behaviour was just broken on issues for like half year or longer until they finally fixed it.
[1]: I haven't evaluated Gogs/gitea/Forgejo in a while though. Also the entire double fork thing is somewhat unfortunate.
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.
I feel like ctrl/cmd f has taken a whole hit in general throughout the whole web. It used to be this really reliable tool that got you quickest where you wanted to go to.
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?
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.
It's a rails app right now, so I'd be surprised if anything else would be slower lol. Except if they really screw up the rewrite or something, but tech wise almost anything else would be faster.
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
Also, if you are an Emacs user, its VC package is very powerful. For example, `C-x v g` to bring up the "blame" (vc-annotate) view, in which you can (for any commit) press `a` to see what the file looked like before that commit, `d` to see the diff of the commit, `l` to see the commit message... That's just the tip of the iceberg of things you can do with it. It supports Git, Mercurial, Bazaar, CVS, Subversion and more as a backend.
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.
Technical caveat: To work effectively, it needs to be able to compile (parse into an AST) the code, which for many GitHub projects is challenging. I'd bet they could easily get to 80% compilation rate though and then use dumb text search on the rest.
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).
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.
Plenty of software from that vintage works better than modern equivalents.
UX is about more than how something looks visually - equally (or more) important is how it behaves, how the user interacts with it, and how it gets out of your way and lets you do your actual work (or doesn't)
I think it's a perfect little detail that captures this writer's persona. Their blog is powered by the (once famed, and very popular) Octopress [0]. Every developer was running their own blog off of it.
My point is, it looks like the author found something that works... for over a decade and well. They wish GitHub would 'just work'
I don't think that the design is that old. I was working as a web designed ~11 years back and a lot of these design ideas were "in" back then. The subtle dark and light 1px lines that create this embedded effect, some shadows around certain elements, not a completely trivial typography. This is a 2010-2014 type of design.
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.
I am just a data set of one, but I disagree. Github the website has worked pretty great for well over a decade at this point. As the author of the post says, it is more recently that some cracks have started to show.
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.
They can apparently be purchased like metrics on any other platform.
People have used them in cons whereby they clone a legitimate project, add a backdoor, then buy the stars and SEO it to get people to clone the bad repo
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.
I hate that content is rendered so inefficiently today that the whole document can't be rendered at once and breaks the browser builtin search. It feels like such a regression in modern software.
Slack does this and I absolutely hate it. It's impossible to search for a keyword in a long thread. The native app will simply hijack the search function, and even opening it on a browser won't work because it only renders the part that's on the screen. I'm sure someone felt really clever when they implemented it.
I don't think they are blaming react specifically. It is more that for them, it dawned that it might due to a rewrite when they remembered reading the front-end was rewritten in react.
`git blame` lets you identify the commit that changed the line you’re looking for, but doesn’t make it easy to then view further details. The author might prefer GitHub’s blame view because it has these features:
• each hunk has a link to the commit that changed it, as opposed to needing to copy a line’s SHA and then run a new `git show …` command
• each hunk has a link to view the `blame` as of that older commit, as opposed to needing to copy a line’s SHA and then run a new `git blame … path/to/same/file` command
• the code is syntax highlighted by default, without you needing to configure your local Git install to use https://github.com/dandavison/delta
These features lead to a better experience than `git blame`. Various IDEs, editor plugins, TUIs, and GUIs provide similar features.
It being a Rails app isn't a problem. A whole bunch of noise and features that have nothing to do with collaboration or managing the versioning of code is the problem.
I like rails myself, not knocking that. Prob well past due for a SPA like experience though. So much of the UI is so antiquated. The fact that very basic things in a PR are hidden beneath a disclosure menu when there is more than enough room to put it in-line without the menu is frustrating. Like simply editing the description of a PR requires 2 clicks when it could easily be 1. Everthing feels bolted-on or shoehorned in. Like marking a PR as a draft ... it took me forever to find that the first time.
#/media/File%3AAM_MacOSX_Panther.png){kind=link}
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...