upvote
I second this. GitHub used to be a fantastic product. Now it barely even works. Even basic functionality like the timeline updating when I push commits is unreliable. The other day I opened a PR diff (not even a particularly large one) and it took fully 15 seconds after the page visually finished loading -- on a $2,000 dev machine -- before any UI elements became clickable. This happened repeatedly.

It is fairly stunning to me that we've come to accept this level of non-functional software as normal.

reply
The trend of "non-functional software" is happening everywhere. See the recent articles about Copilot in Notepad, failing to start because you aren't signed in with your Microsoft Account.

We are in a future that nobody wanted.

reply
Not quite everywhere. There's a common denominator for all of those: Microsoft.

Their business is buying good products and turning them into shit, while wringing every cent they can out of the business. Always has been.

They have a grace period of about 2-4 years after acquisition where interference is minimal. Then it ramps up. How long a product can survive once the interference begins largely depends on how good senior leadership at that product company is at resisting the interference. It's a hopeless battle, the best you can do is to lose slowly.

reply
Things don't always ramp up after 2-4 years. Sometimes MS just kills the project or company after that period of time.

See also their moves in the gaming industry.

reply
Heh, I was working at 2 of those gaming companies when they were acquired by m$. I almost fear taking another job in the gaming industry, there seems to be some kind of bastardised version of Murphy's law that any gaming company that hires me will be acquired by ms 6 months later.

I mean, that's obviously not the case, but it's weird that it happened twice!

reply
I for one am shocked--SHOCKED, I say!--to learn that anything bad could happen as a result of a) putting everything in "the cloud" and b) handing control over the entire world's source code to the likes of Microsoft.

Who could have POSSIBLY foreseen any kind of dire consequences?

reply
Nobody. Nobody at all could have seen it. Microsoft is cool now, haven't you seen VSCode? They do Open Source, they run Linux, they've joined the fold, the tiger shed its stripes.
reply
This thread has complaints about software coming from the same supplier both degrading.

The person(s) who wanted this want Azure to get bigger and have prioritized Azure over Windows and Office, and their share price has been growing handsomely.

‘Microslop’, perhaps, but their other nickname has a $ in it for a reason.

reply
> We are in a future that nobody wanted.

some people wanted this future and put in untold amount of money to make it happen. Hint: one of them is a rabid Tolkien fan.

reply
the irony of Tolkien being associated with a techno-dystopia makes me nauseous
reply
Who is it?
reply
Rent seekers paradise (ft copilot)
reply
It’s just feudal with Capital.
reply
MS PM's wanted it, got their OKR's OK'd, got their bonuses, and moved on.
reply
Laughs in my own Linux distro
reply
> We are in a future that nobody wanted.

Nor deserved.

reply
Then why is it the future we have?
reply
It was a complete accident. Nobody could have foreseen it. We are currently experiencing the sudden discovery that Microsoft is an evil corporation and maybe putting everything in the cloud wasn't the best move after all.
reply
Let’s just say there are a couple of guys, who are up to no good. And they started making trouble in our neighborhood.

jokes aside it’s all because of hyper financial engineering. Every dollar every little cent must be maximized. Every process must be exploited and monetized, and there are a small group of people who are essentially driving all this all across the world in every industry.

reply
Hey from the GitHub team. Outages like this are incredibly painful and we'll share a post-mortem once our investigation is complete.

It stings to have this happen as we're putting a lot of effort specifically into the core product, growing teams like Actions and increasing performance-focused initiatives on key areas like pull requests where we're already making solid progress[1]. Would love if you would reach out to me in DM around the perf issues you mentioned with diffs.

There's a lot of architecture, scaling, and performance work that we're prioritizing as we work to meet the growing code demand.

We're still investigating today's outage and we'll share a write up on our status page, and in our February Availability Report, with details on root cause and steps we're taking to mitigate moving forward.

[1] https://x.com/matthewisabel/status/2019811220598280410

reply
It's insulting to see the word "progress" being used when the PR experience is orders of magnitude slower than it was years ago, when everyone had way worse computers. I have a maxed M5 MacBook and sometimes I can barely review some PRs.
reply
Literally everyone who has used Github to look at a pull request in say the last year has experienced the ridiculous performance issues. It's a constant laughing point on HN at this point. There is no way you don't know this. Inviting to take this to a private channel, along with the rest of your comment really, is simply standard corporate PR.
reply
Yes agreed it's been a huge problem, and we shipped changes last week to address some of the gnarly p99 interactions. It doesn't fix everything and large PRs have a lot of room to be faster. It's still good to know where some worst performance issues are to see if there's anything particularly problematic or if a future change will help.
reply
Hopefully the published postmortem will announce that all features will be frozen for the foreseeable future and every last employee will be focused on reliability and uptime?

I don’t think GitHub cares about reliability if it does anything less than that.

I know people have other problems with Google, but they do actually have incredibly high uptime. This policy was frequently applied to entire orgs or divisions of the company if they had one outage too many.

reply
For what it's worth, I doubt that people think it's the engineering teams that are the problem; it feels as though leadership just doesn't give a crap about it, because, after all, if you have a captive audience you can do whatever you want.

(See also: Windows, Internet Explorer, ActiveX, etc. for how that turned out)

It's great that you're working on improving the product, but the (maybe cynical) view that I've heard more than anything is that when faced with the choice of improving the core product that everyone wants and needs or adding functionality to the core product that no one wants or needs and which is actively making the product worse (e.g. PR slop), management is too focused on the latter.

What GitHub needs is a leader who is willing and able to say no to the forces enshittifying the product with crap like Copilot, but GitHub has become a subsidiary of Copilot instead and that doesn't bode well.

reply
> people think it's the engineering teams that are the problem;

It could be, some people are just terrible at their job. Lots of teams have low quality standards for their work.

Maybe that still comes down to leaders but for different reasons. You can ship useless features without downtime.

reply
Permitting terrible engineers to continue to work for you is a management problem.
reply
So React rewrite did not help after all? Imagine, one of the largest software tool companies on Earth cannot reliably REbuild something in React. I lost count of the inconsistency issues React introduced.

https://news.ycombinator.com/item?id=33576722

reply
React isn't causing these issues.
reply
Then why is the site slower than it was in 2012 on a 2009 Macbook?
reply
Good to know. So it only causes the UI inconsistency bugs.
reply
The new design/architecture allows them to do great stuff in the name of efficiency; for example, when browsing through some parts of the UI, it's now much more capable of just updating the part of the page that's changed, rather than having to reload the entire thing. This is a significantly better approach for a lot of things.

I understand that the 'updating the part of the page that's changed' functionality is now dramatically slower, more unresponsive, and less reliable than the 'reload the entire thing' approach was, and it feels like browsing the site via Citrix over dial-up half the time, but look, sacrifices have to be made in the name of making things better even if the sacrifice is that things get worse instead.

reply
> for example, when browsing through some parts of the UI

React allows this? I didn't realize that I needed React to do this when we used Java and Js to do this 20 years ago. I also didn't realize I needed React to do this when we used Scala and generated Js to do this 10 years ago. JFC, the world didn't start when you turned 18.

reply
This is just microsoft doing the only thing they know, which is taking a good product and turning it into a monster by bashing out whatever feature is on some investors mind that barely even work in a isolated vacuum-sealed test chamber. All microsoft producs are like bad experiments.
reply
I've been a GitHub user since the very early days. I had a beta invite to the service. I really wish they didn't swap out the FE for a React FE.

They need to start rolling back some of their most recent changes.

I mean, if they want people to start moving to self hosted GitLab, this is gonna get that ball rolling.

reply
GitLab is slower for me than that React GH app. Why would I move to GitLab?
reply
Was this a local/on prem version of GL or the hosted web version?

My previous org had an on prem version hosted on a local VM. It was extremely fast, we setup another VM for the runners, and one for storing all the docker containers. The thing I’ve seen people do it use the VM they put their gitlab instance on for everything and ends up bogging things down quite a bit.

reply
Ya, it really was one of the most enjoyable web apps to use pre-MS. I'm sure there are lots of things that have contributed to this downfall. We certainly didn't need bullshit features like achievements.
reply
Even just a year or two ago its web interface was way snappier. Now an issue with a non-trivial number of comments, or a PR with a diff of even just a few hundred or thousand lines of changes causes my browser to lock up.
reply
But even clicking around tabs and whatnot is noticeably slower. It used to be incredibly snappy.
reply
We loved Github as a product when it needed to return or profit beyond "getting more users".

I feel this is just the natural trajectory for any VC-funded "service" that isn't actually profitable at the time you adopt it. Of course it's going to change for the worse to become profitable.

reply
GitHub isn't VC funded at the moment, though. It's owned by Microsoft. Not that this necessarily changes your point.
reply
> Of course it's going to change for the worse

> It's owned by Microsoft.

I see no contradictions here.

reply
I don’t get it. Why making the UI shittier would possibly lead to more profit?
reply
Moving to client-side rendering via React means less server load spent generating boilerplate HTML over and over again.

If you have a captive audience, you can get away with making the product shittier because it's so difficult for anyone to move away from it - both from an engineering standpoint and from network effects.

reply
It seems most of the complaints are about the reliability and infrastructure - which is very much often a direct result of lack of investment and development resources.

And then many UI changes people have been complaining about are related to things like copilot being forcibly integrated - which is very much in the "Microsoft expect to gain a profit by encouraging it's use" camp.

It's pretty rare companies make a UI because they want a bad UI, it's normally a second order thing from other priorities - such as promoting other services or encouraging more ad impressions or similar.

reply
> GitHub used to be a fantastic product. Now it barely even works.

it's almost as if Microsoft bought it, isn't it?

reply
“ I enjoy GH copilot as much as the next person”

So not at all?

reply
That does seem to be the implication, yes. :D
reply
Really? I’d be interested to hear more.

Disclaimer: I work in Microsoft (albeit in a quite disconnected part of it, nothing to do with GitHub or Copilot).

reply
In testing for my workflows copilot significantly underperforms the SOTA agents, even when using the exact same models. It's not particularly close either.

This has lead to 2 classes of devs at my company a) AI hesitant, who for many copilot is their only interaction, having their worst fears confirmed about how bad AI is. b) AI enthusiasts who are irritated by dealing with management that don't know the difference pushing back on their asks for access to SOTA agents.

If I were the frontier labs, and wasn't billions of dollars beholden to Microsoft, I'd cut Copilot off. It poisons the well for adoption of their other systems. I don't deal with the other copilots besides the coding agent variants but I hear similar things about the business application variants.

Microsofts AI reputation is in the toilet right now, I'm not sure if its understood how bad it really is within the org.

reply
I’ve only started using it, so maybe I’m holding it wrong, but the other day I asked the IntelliJ plugin to explained two lines of code by referencing the line numbers. It printed & explained two entirely different lines in a different part of the file. I asked again. It picked two lines somewhere else.

After using ChatGPT for the last 6 months or so, Copilot feels like a significant downgrade. On the other hand, it did easily diagnose a build failure I was having, so it’s not useless, just not as helpful.

reply
Not even Microsoft employees like Copilot. Maybe start why not even your coworkers can use your own slop.

https://www.theverge.com/tech/865689/microsoft-claude-code-a...

reply
The ultimate irony is that Linus Thorvalds designed git with the Linux kernel codebase in mind to work without any form of infrastructure centralisation. No repo trumps any other.

Surely some of your crazy kids can rummage up a CI pipeline on their laptop? 8)

Anyway, I only use GH as something to sync interesting stuff from, so it doesn't get lost.

reply
Setting up a git server for yourself is actually really easy. I use it at home for personal stuff.

https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...

reply
I wonder how many engineers have even worked on a git repo with multiple remotes.

I’ve only worked on a team once where we all were set up as remotes to each other and that was over a decade ago.

reply
hg really spoiled us with these features, though I also haven't used them in ages
reply
We actually did it with raw git in the cli, but I doubt I could set that up correctly nowadays without pouring over the man pages again.
reply
Github used to publish some pretty interesting postmortems. Maybe they still do. IIRC that they were struggling with scaling their SQL db and were starting to hit the limits. It's a tough position to be in because you have to either to a massive migration to a data layer with much different semantics, or you have to keep desperately squeezing performance and skirting on the edge of outages with a DB that wasn't really meant to handle what you're doing with it now. The OpenAI blog post on "scaling" Postgres to their current scale has much the same flavor, although I think they're doing it better than Github appears to be doing.
reply
> Can someone in GitHub senior leadership please start paying attention and reprioritise towards actually delivering a product that's at least relatively reliable?

It's Microsoft. A reliable product is not a reasonable expectation.

reply
Not going to happen. This is terminal decline. Next step is to kill off free repos, and then they'll start ratcheting up the price to the point that they have one small dedicated engineering team supporting each customer they have. They will have exactly one customer. At some point they'll end up owned by Broadcom, OpenText, Rocket, or Progress.
reply
Killing off free repos is not going to happen. That would be a suicide move on the level of the Digg redesign, or Tumblr's porn ban.

It kind of would be good for everyone if they did do it though. Need to get rid of this monopoly, and maybe people will discover that there are alternatives with actually good workflows out there.

reply
They are owned by Microsoft. When has Microsoft ever had a good idea?
reply
Buying Github seems like a good idea? But fucking it up wasn't, so maybe it comes out even.
reply
> Can someone in GitHub senior leadership please start paying attention and reprioritise towards actually delivering a product that's at least relatively reliable?

They claim that is what they are doing right now. [1]

[1] https://thenewstack.io/github-will-prioritize-migrating-to-a...

reply
Zero indication that migrating to azure will improve stability over the colos they are in now. The outages aren’t caused by the datacenter, whatever MS execs say.
reply
Wasn't the last one even caused by Azure?

https://news.ycombinator.com/item?id=46861842

reply
The problem with the GH front end being an unbelievably bloated mess will not be even slightly improved by moving to Azure.
reply
"Migrating to Azure" is, unfortunately, often the opposite of "delivering a reliable product".
reply
Maybe take the initiative and move your own first? It definitely would have a bigger effect than begging here.
reply
deleted
reply
deleted
reply
deleted
reply
My org just moved to Gitlab because of the GH actions problems.
reply
As an aside, God, Azure DevOps, what a total pile of crap that product is

My "favourite" restriction that an Azure DevOps PR description is limited to a pathetic 4000 characters.

reply
My favourite restriction is the fact that colored text doesn't work in dark mode. Why? Because whatever intern they had implement dark mode didn't understand how CSS works, and just slapped !important on all the style changes that make dark mode dark, and thus overwrite the color data.

I ended up writing a browser extension for my team to fix it, because the boss loved to indicate stuff with red/green text.

reply
Amazon's deprecated CodeCommit is limited to 150 chars like it's an old SMS or Tweet.
reply
Ha! Nice. I never worked with CodeStar / CodeCommit. Was it pretty bad?
reply
That's going to depend on each user's demands. The PR message limit is the biggest pain for me. I don't depend on the UI very often. I'm not trying to do any CI/CD nonsense. I just use it as a bog standard git repo. When used as that, it works just fine for me
reply
My favorite is that it doesn't support ed25519 ssh keys.
reply
It shows you the level of quality to expect from a Microsoft flagship cloud product...
reply
So I work for a devtools vendor (Snyk) and 6 months ago I signed into Azure DevOps for the first time in my life

I couldn't believe it. I actually thought the product was broken. Just from a visual perspective it looked like a student project. And then I got to _using_ the damn thing

reply
It's also completely unloved. Even MSFT Azure's own documentation regularly treats it as a second class citizen to GitHub. I have no idea why they don't just deprecate the service and officially feature freeze it.

Honestly that's the case with a lot of Azure services though.

reply
Someone mentioned the boards but Pipelines/Actions are not 100% compliant.

My company uses Azure DevOps for a few things and any attempt to convert to GitHub was quickly abandoned after we spent 3 hours trying to get some Action working.

However, all usability quarks aside, I actually prefer these days since Microsoft doesn't really touch it and it just sits in corner doing what I need.

reply
It's the boards. GitHub issues doesn't let you do all the arcane nonsense Azure DevOps' boards let you do.
reply
Isn’t that a feature?
reply
You would kind of expect with the pressure of supporting OpenAI and GitHub etc. that Azure would have been whipped into shape by now.
reply
AZDO has been in KTLO maintenance mode for years.
reply
You might as well self-host at this point as that is far more reliable than depending on GitHub.

Additionally, there is no CEO of GitHub this time that is going to save us here.

So as I said many years ago [0] in the long term, a better way is to self host or use alternatives such as Codeberg or GitLab which at least you can self host your own.

[0] https://news.ycombinator.com/item?id=22867803

reply
Honestly, Gitlab is pretty decent.
reply