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.
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.
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.
> 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.
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.
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
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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?
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 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 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'
`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.
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.
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 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.
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...
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.
108 comments
[ 3.1 ms ] story [ 201 ms ] threadSame 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.
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.
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.
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.
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.
For example, if you merge the middle branch in a stack of branches, gitlab will retarget the higher branches. Github just orphans them.
It certainly _seems_ like the GitHub interface should feel more like an 'app', and less a 'site'. Or just me?
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.
It's not so much that it isn't an app, but that many of its goals should be similar to browsers.
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.
Wait
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.
https://github.com/jonas/tig
Updating both Git and Git Extensions has seemingly fixed it for me, but the issues I was having were sporadic so maybe I've just been lucky
- Annotate for JetBrains
- GitLens for VSCode
- Magit for Emacs
https://www.sublimemerge.com/
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
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.
Just hire someone who worked for Google and copy their internal code search.
(Preview available here: https://source.chromium.org/)
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.
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.
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.
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.
What means you can expect it continuing downhill until somebody higher up acts.
Not using React would be a much bigger performance optimization.
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
https://www.emacswiki.org/emacs/VersionControl
This feels like a quite dramatic framing for a bug that popped up in a very complex piece of software.
Absolutely amazing platform.
In fact, surprised it has remained high-quality even past acquisition and overwhelming adoption. I would expect scope creep to grow unboundedly.
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.
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.
It's not always the most scalable approach, but I like the DTTCPW "dit-ka-pow": the Dumbest Thing That Could Possibly Work.
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.
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?
It already is. Hit the “.” key in any repo and it literally opens the repo in VS Code in your browser.
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...
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)
But it's the author who is implying that "legacy = bad"
Note: I genuinely love Windows 2000 UI/UX (and wish it still existed today)
My point is, it looks like the author found something that works... for over a decade and well. They wish GitHub would 'just work'
0: http://octopress.org/
Am I the only one who is satisfied running `git blame` in my terminal, using `less` as the pager and searching by pressing `/`?
• 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.
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.
> 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.
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.
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...
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.
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.
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.
Also granular PATs still don’t work everywhere.